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Abstract  and  Executive  Summary 


Hosted  Payloads  are  installed  on  Host  Space  Vehicles  with  available  capacity;  this  approach  is  an 
efficient  use  of  resources  and  reduces  the  time  for  successful  orbital  operation  of  the  Hosted  Payload. 
The  “do  no  harm  analysis”  effort  has  traditionally  focused  on  an  interface  failure  modes  and  effects 
analysis  (FMEA)  to  verify  that  potential  propagating  failure  modes  in  Hosted  Payloads  do  not  affect 
successful  operation  of  the  Hosted  Space  Vehicle’s  primary  mission.  This  FMEA  focused  on  “single 
hard  failures,”  evaluated  their  interface  failure  effects  on  mission  performance  and  verified  that 
design  mitigation  was  present  to  limit  failure  propagation  and  damage,  or  identified  needed  design 
changes  to  limit  the  effects  of  potential  interface  failure  modes. 

When  development  and  delivery  of  the  two  design  configurations  are  not  synchronized,  requirements 
and  performance  incompatibilities  can  pose  potential  risks  to  overall  mission  success.  Contamination, 
electromagnetic  interference  (EMI),  mechanical  layout/integration  and  electrical  interface  design 
integration  are  areas  of  potential  problems.  Because  of  time  pressures  associated  with  meeting 
delivery  milestones  that  satisfy  launch  dates,  mistakes  have  been  made  on  past  programs  and  issues 
have  been  discovered  late  during  the  integration  process.  This  results  in  schedule  slips,  engineering 
rework  or  both. 

Key  decision  points,  requiring  constant  communication,  are  graphically  described  in  Section  3, 
showing  Phases  of  Accommodation.  Phasing  of  the  two  design  configurations  is  discussed  in 
Section  3.2,  Accommodation  Study  and  Gap  Identification.  A  discussion  of  the  gaps  or  potential 
incompatibilities  resulting  from  early/late  participation  in  the  design  process  or  early/late  flight 
hardware  deliveries  for  integration  and  system  test  is  included.  In  some  cases,  a  completed  Hosted 
Payload  design  may  be  a  candidate  for  integration  into  a  Host  Space  Vehicle. 

An  integrated  team  of  engineers  from  The  Aerospace  Corporation  and  contractors  from  across  the 
United  States  worked  as  part  of  the  Mission  Assurance  Improvement  Workshop  (MAIW)  to  share 
their  lessons  learned  and  develop  guidelines  in  the  form  of  checklists  for  improving  the  design 
integration  process  and  likelihood  of  mission  success.  Lessons  learned  with  descriptions  of  the  issues, 
likely  causes  and  corrective  actions  are  summarized  in  a  table.  The  checklists  are  included  in 
Appendix  A  and  include  14  areas  of  expertise,  such  as  contamination  control,  optics,  mechanical  and 
electrical  design  integration.  The  need  for  critical  analyses  to  ensure  compatibility  at  the  interfaces 
and  effect  on  mission  performance  was  also  recognized.  These  analyses  include  failure 
propagation/fault  tolerance,  worst  case  circuit  analysis,  timing  analysis  and  single  events  effects 
(SEE)  analysis  on  both  sides  of  the  interface. 
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1.  Introduction 


1.1  Hosted  Payload  Definitions  and  Terms 

Independently  developed  payloads  can  enter  service  more  economically  using  a  hosted  payload 
approach  than  by  using  a  dedicated  spacecraft  and  launch  vehicle.  A  commercial  operator  or  other 
entity  can  defray  its  own  costs  by  providing  hosted  payload  opportunities  to  an  independently 
developed  payload. 

Recent  hosted  payload  projects  have  met  with  success,  achieving  objectives  that  otherwise  would  not 
have  been  practical.  However,  some  have  also  experienced  avoidable  problems  in  development,  in 
test,  and  on  orbit. 

This  document  was  compiled  by  a  group  selected  from  a  cross-section  of  organizations  in  the  space 
industry.  This  is  the  first  industry-wide  independent  evaluation  of  Hosted  Payload  performance  and 
guidelines.  Its  intent  is  to  advise  those  implementing  hosted  payload  projects,  as  either  a  host  or  as  a 
hosted  payload  provider,  to  potential  risks  that  should  be  considered. 

It  is  intended  primarily  for  those  performing  program  management,  systems  engineering,  design  and 
mission  assurance  activities  on  both  the  host  and  payload  side  of  the  project.  It  will  also  be  useful  to 
any  intermediary  organizations  that  must  manage  information  flow  between  the  host  and  payload  as 
part  of  a  more  extensive  project. 

1.1.1  Terms 

The  following  terms  and  definitions  used  in  this  document  are  derived  from  those  used  in  References 
1  through  4  and  other  sources. 

The  Host ,  in  this  document,  refers  to  the  team  providing  the  Primary  Mission :  the  hosting  spacecraft 
and  its  primary  payload(s).  The  hosting  spacecraft  is  designed,  integrated,  and  tested  by  a  Prime 
Contractor  under  contract  to  the  Owner  and  Operator  of  the  primary  mission.  Either  the  Prime 
Contractor  or  Owner  will  select  the  launch  vehicle  and  provide  launch  services. 

A  Hosted  Payload  is  a  payload  added  to  a  spacecraft  that  is  unrelated  to  the  original  mission(s).  It 
typically  uses  excess  spacecraft  capacity  to  fulfill  its  mission  objectives. 

After  delivery  into  orbit,  the  Hosted  Payload  will  be  operated  as  agreed  between  the  Hosted  Payload 
operator  and  the  primary  mission  Owner/Operator.  Planning  how  to  operate  the  hosted  payload  on 
orbit  is  important  for  success  of  the  mission. 

Programmatic  responsibility  will  vary  from  mission  to  mission.  It  should  be  carefully  defined  and 
agreed  upon  prior  to  commencement  of  the  program.  There  will  likely  be  participants  beyond  the 
provider  of  the  hosted  payload  and  the  Host  involved  in  interface  activities,  to  help  integrate  and 
ensure  proper  operation  of  the  Hosted  Payload  Space  Segment.  Examples  of  hosted  payload 
development  organizations  are  provided  in  References  [1]  and  [2].  The  material  in  this  document  will 
focus  on  the  information  and  properties  that  should  be  coordinated  between  the  Hosted  Payload  and 
the  Host,  since  this  is  independent  of  the  organizations  through  which  necessary  information  passes. 

For  the  remainder  of  this  document,  we  will  refer  to  the  hosted  payload  as  the  Payload.  The 
payload(s)  of  the  primary  mission  will  be  referred  to  as  the  Primary  Payload.  The  figure  below 
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provides  a  generic  picture  of  Host  and  Payload  and  their  responsibilities.  Hosted  payload  projects  can 
have  a  much  more  complicated  structure  than  the  one  shown  here. 


"Payload" 


Hosted  Payload  Operator 

Defines  Hosted  Payload  Requirements 
Oversees  design  &  production  of  Hosted  Payload 
Responsible  for  operation  of  Hosted  Payload 
Designs  and  Operates  Hosted  Payload  Space  Segment 


Hosted  Payload  Provider 

Responsible  for  Production  of  Hosted  Payload 
Procure,  Manufacture,  Integrate  &  Test  HP  components 
Supplies  completed  HP  and/or  components  to  Host 
Provides  Do  No  Harm  safety,  design  &  analysis  info. 


"Host" 


Spacecraft  Owner 

Defines  Primary  Payload  Performance  Requirements 
Procures  Bus  with  Primary  Payload 
Procures  Launch  Vehicle,  directly  or  indirectly 
Receives  remuneration  to  host  secondary  payload 
Responsible  for  Operation  of  the  Spacecraft 
Procures  primary  mission  insurance 


Prime  Contractor 

Responsible  for  Production  of  Spacecraft 
Negotiates,  implements  and  verifies  Primary  Payload  and 
Hosted  Payload  accommodation  requirements 
Integrates  Primary  and  Hosted  Payloads  onto  Bus 
Performs  System  Level  Test 
Arranges  launch  and  conducts  launch  operations 
Validates  Hosted  Payload  will  Do  No  Harm 


Figure  1.  Sample  payload  and  host  organizations. 

1.2  Historical  Hosted  Payload  Challenges 

This  document  is  motivated  by  historical  problems  with  hosted  payload  projects.  Unforeseen 
schedule,  technical,  and  operational  compatibility  issues  have  caused  problems  during  integration,  in 
test  and  on  orbit  for  both  Payloads  and  Hosts.  Compatibility  issues  that  are  not  identified  and 
resolved  in  a  timely  manner  can  “cause  harm”  to  both  the  Host  and  the  Payload. 

These  issues  can  arise  from  unnoticed  gaps  between  the  requirements,  capabilities,  or  configuration  of 
the  Host  and  Payload.  These  gaps  are  more  frequent  in  hosted  payload  projects  because  the  Payload 
and  Host  are  usually  developed  independently,  often  without  knowledge  of  environments, 
requirements,  and  capabilities  on  the  other  side  of  the  interface. 

Out-of-phase  development,  which  is  common  between  a  Hosted  Payload  and  the  Host’s  Primary 
Mission,  can  be  a  major  cause  of  gaps  between  capabilities  and  requirements.  Gaps  can  also  result 
from  compartmentalization;  use  of  previous  designs  that  were  qualified  for  different  applications  and 
from  lack  of  communication,  even  in  co-developed  projects. 

Timely  sharing  of  key  design  information  is  mandatory,  since  design  flexibility  of  the  host  and  hosted 
payload  will  decrease  significantly  as  the  host  and  its  primary  mission  mature. 

The  Payload  provider  may  implement  parts,  units,  or  processes  from  outside  vendors  or  US 
government  sources.  Payload  provider  nondisclosure  agreements  or  security  restrictions  with  these 
sources  that  exclude  the  Host  should  be  avoided,  since  they  may  inhibit  or  significantly  delay  the 
Payload  provider  from  sharing  key  interface  information  with  the  Host,  hindering  the  design  process 
and  increasing  risk. 

Insufficient  or  inadequate  analysis  or  test,  perhaps  resulting  from  these  same  causes,  can  also  result  in 
unanticipated  incompatibilities. 
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1.3  Preventing  Harm 

Harm  that  a  Payload  can  create  at  the  system  level  can  come  from  many  sources,  some  of  which 
might  not  be  apparent  to  a  hosted  payload  provider  accustomed  to  building  instruments  or  payloads 
rather  than  systems.  Similar  problems  can  arise  from  a  host  that  is  not  sufficiently  aware  of  the 
nuances  of  a  specific  Payload.  Sample  harm  that  can  occur  includes: 

•  Noise  and  offsets  due  to  ground  loops 

•  Coupling  of  Electrostatic  Discharge 

•  Arcing  due  to  partial  pressure  from  inadequate  venting 

•  C  ontamination  of  thermal  and  optical  surfaces 

•  Glint  and  other  field  of  view  violations 

•  Ripple  from  antenna  side  lobes  and  other  RF  interference 

•  Use  of  more  resources  than  allocated,  or  allocation  of  less  resources  than  promised 

•  Noise,  shorts  or  excessive  loading  on  shared  data  buses 

•  Attitude  disturbance  or  mechanical  damage  from  moving  or  unsecured  items 

•  Interlock  configurations  or  spurious  emissions  that  violate  launch  safety  regulations 

•  Damage  due  to  the  launch  dynamics  environment 

The  checklists  provided  later  in  this  document  are  intended  to  help  spur  the  thought  process  during 
the  initial  phases  of  a  payload  project.  They  are  based  on  the  experiences  of  individuals  in  our  group 
and  of  their  companies.  They  do  not  provide  a  cookbook  for  hosting  payloads,  nor  should  they  be 
considered  a  replacement  for  the  Systems  Engineering  process  that  is  required  to  appropriately  host  a 
payload. 

The  Host  Should: 

•  Define  interfaces  early  and  maintain  configuration  control 

•  Budget  and  provide  committed  resources  to  the  Payload 

•  Identify  any  faults  that  can  propagate  to  the  Payload  so  they  may  be  appropriately  mitigated 

•  Not  have  single  faults  that  impede  the  Payload  mission  beyond  agreed-upon  provisions 

•  Not  expose  the  Payload  to  damaging  environments  in  normal  or  contingency  operations 

The  Payload  Should: 

•  Strictly  adhere  to  interfaces  negotiated  with  the  Host 

•  Identify  any  unmitigated  propagating  faults  so  they  may  be  mitigated  by  the  Host 

•  Stay  within  agreed  upon  allocations,  even  in  fault  conditions 

•  Not  impact  the  primary  mission  beyond  agreed  upon  constraints 
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2.  References 


2.1  Reference  Documents 

Documents  listed  in  Table  1  provide  good  references  for,  and  examples  of,  interface,  environment, 
and  procedural  requirements.  They  are  called  out  in  the  body  of  this  text  as  relevant. 

2.2  Additional  Reference  Documents 

Additional  reference  documents  are  provided  in  Appendix  A,  in  support  of  the  checklists  located 
there. 


Table  1.  Table  of  Reference  Documents 


Ref 

Document 

Reference 

Intent 

1 

Commercially  Hosted  Payload 
Implementation  Policy 

Goddard  Interim  Directive 

GID  7120.2 

An  example  of  organizational 
roles  and  responsibilities. 

2 

Hosted  Payload  Solutions  Statement 
Of  Work 

FA8814-13-R-0001,  1 

August  2013,  Section  1.3 

An  example  of  organizational 
roles  and  responsibilities. 

3 

Hosted  Payload  Standard  Interface 
Specification 

HPSIS,  Space  and  Missile 
Systems  Center,  Hosted 
Payload  Office 

An  example  hosted  payload 
interface  specification. 

4 

Hosted  Payload  Guidelines 

Document  (Common  Instrument 
Interface  Requirements) 

National  Aeronautics  and 
Space  Administration 
Document  CII-CI-0001, 

Rev  A 

An  example  hosted  payload 
interface  specification. 

5 

Criteria  For  Flight  and  Flight  Support 
System  Lifecycle  Reviews 

GSFC-STD-1001A 

An  example  set  of  evaluation 
criteria  that  can  be  tailored  to 
a  specific  program. 

6 

General  Environmental  Verification 
Standards  (GEVS),  for  GSFC  Flight 
Programs  and  Projects 

NASA  Goddard  Space  flight 
Center,  GSFC-STD-7000, 

April  2005 

A  generic  Environmental 
Requirements  Document. 

7 

Test  Requirements  For  Launch, 
Upper-Stage,  &  Space  Vehicles 

SMC-S-016 

A  generic  Test  Requirements 
Document. 

8 

NASA  SE  Handbook,  Appendix  L, 

IRD  Outline 

NASA  SP-2007-6105 

An  example  outline  for  an 
Interface  Requirements 
Document  that  can  be  tailored 
to  the  needs  of  a  specific 
mission. 

9 

Space  Vehicle  Failure  Modes, 

Effects,  and  Criticality  Analysis 
(FMECA)  Guide 

Aerospace  Report 

TOR-2009  (8591  )-1 31 

Descriptive  document  on 

Failure  Modes,  Effects  and 
Criticality  Analysis. 

10 

Lessons  Learned  from  Hosting  an 
Infrared  Payload  on  a 

Communications  Satellite 

J.  Simonds,  Space  and 

Missile  Systems  Center 

Interesting  case  study 
describing  some  Hosting 
challenges. 

11 

Guideline  for  Space  System  Late 
Changes  Verification  Management 

Aerospace  Report 
TOR-2008(8506)-8377 

Includes  case  studies  of 
undesired  consequences  from 
late  changes  that  should  be 
avoidable. 
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Test  Like  You  Fly:  Assessment  and 
Implementation  Process 

Aerospace  Report 

TOR-201 0(8591  )-6 

Describes  an  assessment 
approach  to  evaluating 
mission  related  risks  and 
potential  flaws  in  space 
systems. 
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3.  The  Accommodation  Process 


The  phases  of  accommodation  are  shown  in  Figure  2.  Accommodation  begins  with  identification  of  a 
hosting  opportunity  (Section  3.1).  After  a  reasonable  opportunity  has  been  identified,  an 
accommodation  study  can  be  performed  to  identify  any  requirement/capability  gaps  at  the  Payload 
interface  (Section  3.2).  Detailed  design  is  performed  to  resolve  gaps  and  mitigate  risk  (Section  3.3). 
The  Payload  and  Flost  are  integrated  as  illustrated  in  Figure  3,  then  testing  verifies  the  interfaces  and 
combined  system  (Section  3.4),  allowing  the  project  to  proceed  to  launch  and  operations.  Frequent 
interaction  is  required  between  the  Flost  and  Payload  during  the  design  and  planning  phases  to  ensure 
the  accommodation  process  is  successful. 


Opportunity 

Identification 


Accommodation  Study  / 
Gap  Identification 


Detailed  Design  and  Gap 
Resolution 


Integration,  Verification 
and  Test 


Operations 

Figure  2.  Phases  of  accommodation. 

3.1  Opportunity  Identification 

There  may  be  a  planned  or  existing  payload  and  a  planned  or  existing  host  that  identifies  the 
opportunity  for  a  business  arrangement.  An  intermediary  might  also  perceive  and  propose  such  an 
arrangement.  It  is  expected  that  basic  properties  be  matched  to  the  first  order  during  this  opportunity 
phase.  Basic  properties  to  evaluate  for  a  compatible  host  opportunity,  sometimes  referred  to  as  size, 
weight,  area,  and  power  (SWAP)  would  include: 

•  Available  Footprint  Area 

•  Accommodation  of  Stowed  and  Deployed  Volume 

•  Available  Mass 

•  Available  Power 

•  Temperature  and  Thermal  Dissipation  Capability 

•  Available  Command,  Telemetry  and  Mission  Data  Flandling  and  Transport  Bandwidth 

•  Appropriate  Data  Interface  Capacity  and  Compatible  Protocols 
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•  Potential  Fields  of  Regard  (  Optical  and  RF)  plus  Thermal  view  factors 

•  Frequency  Compatibility 

•  Mission  Compatible  Orbits 

3.2  Accommodation  Study  and  Gap  Identification 

An  important  next  step  is  to  identify  gaps  between  the  designed  and  qualified  capabilities  of  the 
Payload  and  the  environments  in  which  they  will  be  used,  so  that  design  of  any  required  Payload 
modifications  or  Flost  accommodations  can  begin. 

Incompatibilities  and  gaps  between  requirements  and  capabilities  of  the  Host  and  Payload  require 
identification  and  resolution.  A  Gap  Analysis  is  a  structured  method  for  identifying  and  recording 
these  incompatibilities. 

Gaps  may  result  from: 

•  Untimely  communication  of  Requirements,  Interfaces  or  Environments 

•  Payload  qualified  environments  that  differ  from  those  on  the  host 

•  Payload  design  capabilities  that  differ  from  those  required  by  the  host 

•  Late  changes  in  requirements 


Host  Environments 

•  Launch  loads  /  dynamics 

•  Shock 

•  Radiation  Shielding 

•  Thermal  conductivity 

•  Magnetic  &  Electric  Fields 

•  On-orbit  loads,  resonances 

•  Stationkeeping  &  pointing 


Analysis  of  Gaps  considers  the  same  criteria  for  any  relative 
phasing  of  development  between  the  Host  and  Payload 


Payload  Qualified  Environments 

•  Sine,  Random  and/or  Acoustics 

•  Shock 

•  ESD 

•  Temp  range,  operating,  test  and  survival 

•  Life 

•  Power  handling,  breakdown 

•  EMI  /EMC 


Environmental 

Payload 

Properties 

Gap  Analysis 

Capabilities 

Interface 

Payload 

Descriptions 

Interfaces 

Payload  Analyzed  Properties 

•  Heat  flux  densities  &  location 

•  Mechanical  resonances 

•  Radiation  resistance 

•  SEE  rates 

•  Venting 

•  Failure  Modes 

•  Reliability  &  Stress 


Host  Interface  Descriptions 

•  Power  bus  voltage  and  stability 

•  Data:  physical,  protocol  &  rates 

•  Telemetry  and  Command 

•  Thermal  conductivity 

•  Mounting  method  /  strength 

•  Grounding 


Payload  Interface  Descriptions 

•  Needed  power  bus  voltage  and  stability 

•  Data:  physical,  protocol  &  rates 

•  Telemetry  and  Command 

•  Thermal  dissipation 

•  Mounting  method,  configuration  &stress 

•  Grounding 


Figure  3.  Identification  of  gaps. 

Critical  gaps  or  differences  may  require  accommodation  through  design,  analysis,  test  or  operational 
modifications.  These  should  be  identified  and  tracked  until  resolved. 

Conceptual  program  flow  and  phasing  is  illustrated  in  Figure  3.  Movement  of  Payload  development 
earlier  or  later  in  relation  to  the  Host  can  result  in  disconnects  or  gaps  in  properties,  handoffs,  and 
information  exchange.  Disconnects  can  result  in  the  need  to  make  late  modifications  to  one  side  of  the 
interface  or  the  other. 
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The  graphic  illustrates  two  of  many  possible  approaches.  The  sequence  in  the  vertical  center 
represents  flow  of  units  to  be  installed,  with  the  downward  arrow  going  directly  to  the  spacecraft, 
while  the  upward  path  represents  units  installed  on  an  intermediary  tower  or  enclosure. 

When  there  is  lack  of  appropriate  phasing  between  Payload  and  Host  development,  the 
environmental,  interface,  and  physical  properties  of  the  Host  and  Payload  are  unlikely  to  match,  and 
accommodations  will  be  required. 

To  achieve  maximum  risk  reduction,  the  Payload  should  be  available  for  integration  with  the  Host 
prior  to  all  relevant  system  level  testing.  To  further  mitigate  interface  risks,  flight-like  or  high  fidelity 
simulators  should  be  exchanged  to  allow  actual  interface  testing  and  verification. 

Though  gaps  may  arise  due  to  out-of-phase  development  and  other  causes,  the  actual  properties  that 
must  be  aligned  are  the  same  for  any  sequence  of  development  or  for  any  cause. 

An  analysis  to  discover  gaps  should  include  a  methodical  comparison  of  the  nominal  environments 
that  the  Payload  will  experience  to  those  that  its  components  and  the  Payload  have  been  designed  to 
and  qualified  for.  It  should  also  include  a  survey  of  areas  of  potential  incompatibility  such  as  required 
cleanliness. 

When  gaps  are  identified,  a  process  of  resolution  can  be  initiated.  Modification  of  Host  environments, 
such  as  temperature,  dynamic  stress,  mechanical  load  or  radiation  can  be  accomplished  as  a  means  of 
accommodating  a  Payload  that  does  not  conform  to  baseline  requirements. 

Alternatively,  the  Payload  may  be  found  adequate  by  analysis  or  be  modified  by  stiffening,  shielding, 
requalification,  redesign  or  other  means. 
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Hosted  Payload  Panel.  Tower.  Enclosure,  if  employed 


Heritage  Evaluation 

•  Evaluate  any  existing  designs 

•  Qualification  vs.  LV  +  SC  loads 

•  Qualification  vs.  expected  temperatures 

•  Design  vs.  life  and  radiation 

•  Design  &  test  vs.  EMI  &  magnetic  environment 

•  Sensitivity  vs.  cleanliness  of  environments 

•  Identify  Gaps  and  resolve  during  design  phase 


Define  thermal 

Build  or  Order 

Build 

Integrate  and 

Deliver  to 

design 

Structure 

Harness 

Test  Payload 

Host 

n 


Hosted  Payload  Units 


Payload 


Concept  Detailed  Design 
Design  and  Analysis 


Manufacturing 


Test 


Deli  rery 


■o 

(T) 

aT 


Can  It  Fit? 

•  Volume,  stowed  &  deployed 

•  Footprint  area 

•  Mass,  not  to  exceed 

•  Power,  not  to  exceed 

•  Thermal  dissipation  (nte) 

•  FOV:  Optics,  RF  &  radiator 

•  Frequency  compatibility 

•  Lifetime 

•  Operational  Modes 

•  Data  capacity,  modes,  protocol 

•  Other  Unique  aspects 


Mechanical  &  Thermal 

Heat  flux  densities  &  location 
Temp  range,  op  &  non-op 
Final  footprint 
Mounting  holes  &  hardware 
Connector  types  &  locations 
Power  &  Thermal,  all  op  modes 
Vent  locations 
Heaters  /  thermistors 
Bonding  and  grounding 


Harness  &  Electrical 

•  Connector  pinouts 

•  Interface  circuitry/ analysis 

•  Voltages  /  Inrush  currents 

•  CS/CE  and  grounding 

•  Redundancy  requirements 

•  T&C  interfaces 

•  Data  bus  interfaces  &  protocols 


■o 

fD 

rf 


Concept  Design 

•  T&C  interfaces  (budget  by  type) 

•  Data  bus  interfaces  and  protocols 

•  Heat  Flux  Density  (operating) 

•  Temp  ranges 

•  Power  and  Thermal  (preliminary) 

•  Heater  (preliminary)  needed  for  above 

•  Redundancy  Requirements 

•  Data  bus  budget 


Detailed  Design 

•  Final  Footprint 

•  Vent  locations 

•  Mounting  holes  and  HW 

•  Connector  types,  locations  &  Pin  outs 

•  Interface  Circuitry  Analysis 

•  Voltages  and  Inrush  current  (transients) 

•  Final  Power  and  Thermal,  all  modes 

•  Failure  modes 

•  Data  bus  interfaces,  loading  &  margins 

•  Stress  margins 


Pre¬ 

pairing 

Concept  Design 

Detailed  System 
Design 

Configuration 

Design 

Mechanical  Assembly 

ID 


QJ_ 

"O 

(1) 


O 

CD 

CL 


System  Integration 


Pre  Award  Activities 


Contract  Phase:  Satellite  Design,  Integration  and  Test 


Figure  4.  Optimally  phased  payload  and  host  development. 


Payload  Structure 


Early  independent  development  of  a  payload,  prior  to 
definition  of  host  environments  and  requirements,  will  lead  to 
gaps  between  the  design-to  requirements  and  those  in  use. 


Late  delivery  will  cause  critical  system-level  verification 
testing  to  be  missed,  perhaps  requiring  high  fidelity 
simulators,  emulators  or  mass  dummies. 


Optimally  Phased  Payload  and  Host  Development  will 
Minimize  Disconnects  and  Allow  Appropriate  Test. 


Requirement  and  interface  disconnects  for  any  cause  will 
necessitate  modification  and  verification  on  the  Host  or 
Payload  side  of  the  interface. 


Host 


System  Test 


Delivery, 

Launch 

In-orbit 

Post  Launch 

Shipment 

Activities 

Test 

Support 

Acceptance,  Shipping  and  Launch 


Post  Launch  Activities 


If  Payloads  have  significant  thermal  and  structural  interaction  with  the  host,  those  designs  will  require  an 
early  start  to  ensure  basic  Host  properties  do  not  require  change  late  in  the  program. 

Mass,  Power,  Thermal  and  other  budgets  should  be  established  early,  and  tracked  throughout  the  project 
(Section  3.3.2). 

Physical  layout  of  equipment  that  might  be  co-located  with  primary  mission  equipment  is  a  key 
consideration  for  accessibility,  servicing  and  removal  if  necessary.  Harness  and  electrical  interface 
design,  including  routing  and  grounding  would  follow  physical  layout. 

Ideally,  interface  and  other  analyses  will  be  completed  prior  to  actual  manufacture  and  test  of  Payload  and 
interfacing  Host  hardware  and  software  (Section  3.3.4). 

Integration  and  system  level  test  (Section  3.4)  should  be  performed  according  to  the  ideal  flow  shown  in 
Figure  3  if  possible.  Deviations  from  this  flow  might  necessitate  the  provision  of  high  definition 
emulators  or  simulators. 

Launch  and  Initial  On  Orbit  Test  (IOT)  and  operation  on  orbit  come  at  the  end  of  the  development  phase, 
but  these  and  the  eventual  decommissioning  of  the  Payload  should  be  planned  well  in  advance. 

Handoffs  and  deliverables  required  to  implement  the  program  should  be  tracked  continuously 
(Section  3.3.14).  Key  decision  points  will  vary  depending  on  program,  but  they  should  be  established 
early  and  adhered  to.  Decision  points  as  important  as  whether  or  not  to  include  the  Payload  on  the  mission 
should  be  planned  at  points  in  the  schedule  where  there  is  sufficient  time  to  react,  and  alternatives  such  as 
mass  simulators  and  closeouts  should  be  planned,  designed,  or  fabricated  to  support  possible  occurrences. 

To  achieve  maximum  risk  reduction,  the  Payload  should  be  available  for  integration  with  the  Host  prior  to 
all  relevant  system  level  testing.  To  further  mitigate  interface  risks,  flight-like  or  high  fidelity  simulators 
should  be  exchanged  to  allow  actual  interface  testing  and  verification. 

As  an  added  aid  in  gap  identification  and  alignment  of  properties,  checklists  were  developed  in  disciplines 
common  across  the  space  industry.  These  checklists  are  not  meant  as  a  substitute  for  the  Systems 
Engineering  Process,  but  as  a  refresher  for  management  and  systems  engineering  management  to  spark 
discussions  in  these  and  other  areas. 

Checklists  for  each  of  the  areas  below  are  provided  in  Appendix  A. 

•  Attitude  and  Orbit  Control 

•  Command  and  Data  Handling 

•  Configuration  Management 

•  Contamination  Control 

•  Electrical  Interface  Design  and  Integration 

•  EMI/EMC 

•  Fault  Management 

•  Materials  and  Processes 

•  Mechanical  Layout  and  Integration 

•  Optics 

•  Power 
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•  Safety,  Reliability  /  FMECA 

•  Structural,  Mechanical,  Alignments,  and  Mass  Properties 

•  Thermal 

3.3  Detailed  Design  and  Gap  Resolution 

When  gaps  are  identified,  a  process  of  resolution  can  be  initiated.  Modification  of  Host  environments, 
such  as  temperature,  dynamic  stress,  mechanical  load,  or  radiation  can  be  accomplished  as  a  means  of 
accommodating  a  Payload  that  does  not  conform  to  baseline  requirements.  Alternatively,  the  Payload  may 
be  found  adequate  by  analysis  or  be  modified  by  stiffening,  shielding,  requalification,  redesign  or  other 
means.  The  risk  due  to  any  unresolved  gap  is  by  default  being  assumed  when  it  is  not  mitigated  in  some 
form  and  this  must  be  consistent  with  the  overall  programmatic  risk  position. 

3.3.1  Mission  Operations  Concepts 

Early  development  and  definition  of  mission  operations  concepts  is  required  to  ensure  mission  success. 
Interaction  between  ground  systems  of  the  Host  and  Payload,  of  networks  and  operators  can  be  complex. 
Operations  will  vary  greatly  depending  on  each  mission  configuration.  While  design,  planning,  and 
construction  of  mission  infrastructure  is  beyond  the  scope  of  this  document,  there  are  considerations  that 
will  be  common  across  many  Payload  missions.  Table  2  provides  a  starting  point  for  mission  planning 
from  the  perspective  of  Host  and  Payload  interactions. 

Table  2.  Mission  Operations  Considerations 


Topic 

Aspect 

Considerations 

Mission  Data 

Communication  of 
mission  data  from  the 
hosted  payload 

Data  Bus  Interface  (type  and  rate) 

Short  term  storage  for  mission  data 

Use  of  the  host  data  system,  e.g.  for  low  speed  telemetry 

Communication  with 
ground 

Dedicated,  payload  provided  links,  e.g.  for  high  data  rate 
Common  use  of  Host  ground  station  links 

Position  and 

Orientation 

Orbital  Position, 
Orientation,  Velocity 
and  Time  Information 

Time  stamp,  clock  latency  and  accuracy 

Does  mission  require  information  on  board  or  on  ground 

Commanding  and 
Telemetry 

Payload  commanding 
via  the  host 

Payload  commands  and  telemetry  may  be  interleaved  by 
the  host  and  sent  embedded  to  the  ground  with  other 
data  required  by  the  host. 

Payload  commanding 
via  dedicated  ground 
links 

Care  must  be  taken  to  ensure  the  correct  minimum  set  of 
commands  and  telemetry  is  available  as  a  backup  via  the 
host  in  order  to  accomplish  any  required  contingency 
responses. 

Mission  Planning 

Coordination  of 
operations  between 

Host  and  Payload 
control  centers 

Things  such  as  simultaneous  commanding  from  each 
center  can  be  problematic.  The  Host,  as  an  operational 
mission,  will  have  operational  priority  and  should  define 
constraints  on  the  Payload. 

Fault  Management 
and  Contingency 
Operations 

3.3.2  Budgeted  and  Expendable  Items 

Budgeted  and  expendable  items  include  mass,  power,  thermal  dissipation  and  data  bandwidth.  Most 
budgeted  item  interface  requirements  are  defined  as  “Not-To-Exceed”  for  the  Payload  and  “No-Less- 
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Than”  for  the  Host.  For  example,  the  Payload  peak  power  must-not-exceed  some  number  of  watts  and  the 
Host  must  provide  no-less-than  the  same  number  of  watts.  This  allows  both  sides  to  perform  their  design 
and  analysis  activities  as  independently  as  possible.  It  is  also  incumbent  on  each  side  to  manage  the 
margin  to  these  requirements.  In  the  early  phases  of  design,  estimates  may  be  rough  and  growth  is 
expected  as  part  of  the  detailed  design. 

It  is  important  to  ensure  that  both  the  Host  and  Payload  are  using  the  same  definitions  for  margin  in  order 
to  understand  expected  growth  vs  excess  above  that  expectation.  It  is  important  that  estimates  are  accurate 
because  there  is  no  benefit  in  carrying  unneeded  margin,  and  there  can  be  harm  such  as  inaccurate  centers 
of  mass  during  late  stages  of  a  program. 

Many  items  are  managed  via  budgets  during  the  design  of  the  space  element.  In  this  document,  we  are 
assuming  that  the  host  spacecraft  has  been  designed  to  meet  the  primary  mission  requirements  and  that 
the  link  and  primary  mission  pointing  budgets  are  being  met  before  hosting  additional  payloads. 

The  following  budgets  can  be  affected  by  the  addition  of  a  hosted  payload.  Most  allocations  should  be  for 
the  Payload  life,  though  certain  aspects  might  be  applicable  for  the  Host  mission  life  (e.g.,  propellant). 

Table  3.  Budgets  That  May  Be  Impacted 


Item 

Comment 

Potential  Mitigation 

Mass 

Need  to  consider  the  location  of 
the  center  of  mass. 

Measurement  as  early  as  possible 
reduces  risk.  Need  to  consider  mass 
simulator  to  protect  host  launch  window. 

Average  Payload  Power 

Both  BOL  and  EOL.  Host  must 
consider  orbit  constraints. 

Hosted  payload  life  may  be  significantly 
shorter  than  that  of  the  Host.  Payload 
power  usage  in  all  modes  should  be 
measured  as  part  of  acceptance  testing. 

Peak  Payload  Power 

Both  BOL  and  EOL.  Host  must 
consider  orbit  constraints.  Typically 
driven  by  Payload  operations  but 
must  consider  all  payload  modes 
and  transitions.  Defines  fusing 
design. 

Hosted  payload  life  may  be  significantly 
shorter  than  that  of  the  Host.  Payload 
power  usage  in  all  modes  should  be 
measured  as  part  of  acceptance  testing. 

Survival  Payload  Power 

Power  required  by  survival  heaters 
and  any  other  necessary  support 
equipment  that  operates  during 
this  period. 

Payload  power  usage  in  all  modes 
should  be  measured  as  part  of 
acceptance  testing. 

Power  during  launch  and 
early  operations 

Drives  maximum  depth  of 
discharge  for  battery. 

Payload  power  usage  in  all  modes 
should  be  measured  as  part  of 
acceptance  testing. 

Pointing  and  Alignment 

Short  term  (transients,  jitter)  and 
long  term  (diurnal,  seasonal). 
Induced  jitter,  torque,  and 
momentum  exchange  are  factors 
to  consider. 

Short  term  is  driven  by  onboard 
mechanisms.  Use  of  damping  or 
isolation  can  protect  the  other  side  of  the 
interface.  Long  term  is  driven  by  thermal 
expansion  mismatch.  Heaters  can  be 
used  to  minimize  the  impact. 

Average  Conducted 

Thermal  Dissipation 

Need  to  define  a  maximum  thermal 
transfer  rate  for  design. 

Conduction  to  a  heat  pipe  panel  may  be 
considered  for  payloads  with  high 
dissipation. 

Peak  Conducted  Thermal 
Dissipation 

Needs  to  consider  all  operational 
modes  and  transitions. 

Worst  case  conduction  may  bound  size 
and  materials  of  thermal  interface. 

Average  Radiated  Thermal 
Dissipation 

Backload  on  Host  or  Payload  can 
be  important. 

Careful  review  of  payload  radiator  fields 
of  view  vs.  Host  configuration  can 
reduce  risk. 
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Item 

Comment 

Potential  Mitigation 

Siqnals  (bv  type) 

Clock 

Analog 

Bi-level 

Pulse 

Relays 

Quantity,  format  and  logic 
convention  must  be  addressed  in 
ICD. 

Early  testing  of  hardware  (breadboard/ 
brass  board)  can  avoid  late  discovery  of 
design  issues.  Use  of  simulators  can 
help  ensure  incompatibilities  are 
identified  early. 

Telemetry  (bv  tvoe) 

Data  bus/Digital 
Analog/Thermistor 

Bi-level 

Quantity,  format  and  logic 
convention  must  be  addressed  in 
ICD. 

Early  testing  of  hardware  (breadboard/ 
brass  board)  can  avoid  late  discovery  of 
design  issues.  Use  of  simulators  can 
help  ensure  incompatibilities  are 
identified  early. 

Command  and  Telemetry 
Data  rate 

Command  and  Telemetry  bus 
utilization. 

Separating  Payload  C&T  bus  can 
minimize  the  risk  of  contention  between 
Host  and  Payload  messages. 

Mission  Data  Rate 
(Average) 

Data  bus  and  ground  link 
utilization. 

A  separate  payload  data  bus  and/or 
downlink  can  reduce  Host  bus  and  link 
utilization. 

Mission  Data  Rate  (Peak) 

Host  may  have  capacity  for  much 
higher  data  rates  over  shorter 
periods. 

A  separate  payload  data  bus  and/or 
downlink  can  reduce  Host  bus  and  link 
utilization. 

Processing  Capability 

Goal  should  be  to  minimize 
payload  processing  requirement 
for  host. 

Ground  processing  can  reduce  on-board 
requirements. 

Memory  Utilization 

Goal  should  be  to  minimize 
memory  utilization  for  Host 
spacecraft  applications  required  to 
operate  Payload. 

Early  software  testing  can  avoid  late 
discovery  of  issues. 

Data  Storage  Capacity 

When  host  is  providing  storage. 

When  payload  provides  data  storage, 
the  limit  becomes  data  bus  and  ground 
link. 

Link  Utilization 

Affected  by  orbit,  pointing,  C&T  or, 
mission  data  rates. 

Payload  dedicated  ground  link. 

Propellant 

Affected  by  payload  mass  for 
station  keeping.  Affected  by 
payload  imbalance  for  momentum 
unloading. 

Perform  early  system  level  analysis  to 
optimize  Payload  placement  and  Host 
propulsion  system  flexibility. 

3.3.3  Environments 

Environments  to  which  the  Payload  was  designed,  analyzed,  and  tested  should  be  compared  to  those 
provided  by  the  host.  Baseline  environments  may  be  available  in  host  environmental  requirements 
documents.  Reference  6,  the  NASA  GEVS  document,  provides  a  good  listing  of  environments  that  should 
be  evaluated  should  a  Host-specific  document  not  be  available. 

It  is  recommended  that  Hosts  publish  a  handbook  or  guide  describing  their  environments  for  hosted 
payloads  so  that  prospective  Payloads  can  be  designed  to  be  compatible  from  the  start.  It  should  be  feasible 
for  both  Payload  developers  and  Hosts  to  minimize  non-recurring  compatibility  effort  by  designing 
compatibility  in  from  the  start. 

Existing  payloads  or  their  components  may  not  be  qualified  to  the  environments  of  a  specific  host.  Shock 
and  vibration  reduction  techniques  may  be  required  if  the  units  cannot  be  qualified  to  the  predicted  levels. 
Alternatively,  flight  units  may  require  additional  testing  in  order  to  mitigate  risk. 

Table  4  provides  a  list  of  key  environments  that  should  be  considered.  This  list  is  not  meant  to  be 
exhaustive.  Other  derived  environmental  requirements  that  might  be  relevant  include  magnetic  fields, 
magnetic  moments;  micrometeoroid  resistance;  and  atomic  oxygen  resistance  for  certain  low  earth  orbits. 
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Table  4.  Key  Environments 


Environment 

Comment 

Potential  Mitigation 

Shock  (launch  and  on- 
orbit) 

Can  vary  significantly  by 
launch  vehicle,  placement  of 
the  Payload  or  missions. 

•  Placement  in  low  shock  areas 

•  Use  of  specialized  shock  reduction 
techniques 

•  Adding  a  secondary  structure  for  the  Payload 
can  also  act  as  a  dampener  if  placed  in  the 
correct  location 

Launch  Loads 
(sine,  random  and 
acoustic) 

Will  vary  considerably  by 
launch  vehicle  and  Payload 
location  on  the  Host. 

•  Local  or  spacecraft-level  damping  techniques 
can  be  used  (CSA  Soft  Ride  is  an  example) 

•  Notching  to  prevent  overtest 

Temperatures 

Host  may  need  to  support 
thermal  control  of  the 

Payload. 

•  External  heatpipes 

•  Radiators 

•  Thermal  spreader  plates 

•  Thermal  isolation 

Depressurization  rates 

Depressurization  rates  are 
higher  for  many  of  the  GEO 
launchers  than  for  LEO 
launchers. 

A  relatively  easy  calculation  will  allow  proper 
vent  hole  sizing 

Partial  Pressure 

Partial  pressure  during  launch 
and  thermal  vacuum  pump 
down  and  repressurization 
can  cause  effects  such  as 
corona  or  multipaction. 

Not  powering  the  Payload  during  launch  and 
pump  down  would  be  a  good  mitigation. 

Otherwise,  test  should  be  performed  to  ensure 
survival  of  susceptible  equipment. 

Vacuum 

Though  most  space  hardware 
is  designed  to  operate  in 
vacuum,  many  COTS 
products  are  not. 

Special  analysis  or  test  might  be  required  to 
ensure  COTS  will  operate  without  convective 
cooling 

Radiation 

Radiation  environments  will 
vary  depending  on  orbit,  Host 
design  and  style  of  launch. 

The  radiation  environment  should  be  specified 
by  the  Host  at  the  location  of  the  Payload 
equipment.  Additional  shielding  may  be  applied 
by  the  Payload  to  ensure  equipment  will  operate 
under  worst  case  conditions  for  the  required 
duration. 

Electromagnetic 
Interference  and 
Compatibility 

Potential  interference  from  the 
Host;  and  stay-out 
frequencies  required  by  the 

Host  can  vary  from  mission  to 
mission. 

Analysis  and  test  are  required  to  ensure  there  is 
no  frequency  interference  between  the  Host  and 
Payload.  Additional  filtering  or  shielding  may  be 
required  when  frequency  bands  or  their 
harmonics  are  adjacent. 

Magnetic  Fields 

Electromagnetic  fields  can 
interfere  with  instruments 
such  as  magnetometers,  can 
affect  attitude  and  could 
conceivably  disturb  other 
equipment. 

Specify  and  respect  magnetic  field  generation 
and  susceptibility  of  both  the  Host  and  Payload. 

Space  Charging 

High  voltage  potentials  can 
build  up  on  isolated  or 
insufficiently  grounded 
surfaces.  Also  in  highly 
insulating  materials.  Either 
can  result  in  damaging  arcs  or 
discharges. 

Analysis  and  testing  are  required  to  ensure 
there  is  sufficient  ESD  grounding  and  that  all 
signal  and  power  returns  are  grounded  to  the 
appropriate  ground  planes. 

3.3.4  Critical  Analyses 

Analyses  required  to  ensure  compatibility  between  a  Payload  and  Host  are  very  similar  to  those  required 
to  demonstrate  compatibility  between  any  other  spacecraft  components. 

Since  engineering  may  have  been  performed  independently  on  each  side  of  the  interface,  proper 
understanding  and  analysis  of  the  interfaces  is  critical  to  the  success  of  the  project. 
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Structural,  thermal,  performance,  and  other  analyses  that  are  normal  for  spacecraft  development  are  also 
required.  Structural  and  thermal  analyses  are  of  special  importance  for  most  Payload  configurations. 

Table  5.  Critical  Analyses 


Analysis 

Purpose 

Reliability  /  Redundancy  (3.3.5) 

Ensure  that  the  redundancy  architecture  of  the  Host 
and  Payload  are  compatible  to  meet  the  mission  life 
and  reliability  requirements. 

Single-Point  Evaluation  (3.3.6) 

Ensure  that  potential  failure  modes  that  put  the  Host 
or  Payload  at  risk  have  design  fault  mitigation  or 
processes  in  place  to  reduce  the  likelihood  of  failure. 

Host  Failure  Propagation  and  Fault  Tolerance 
(3.3.7) 

Ensure  that  propagating  faults  by  the  Host  are 
identified  to  the  Payload  for  mitigation  and  the 
identified  propagating  faults  from  the  Payload  are 
mitigated  by  the  Host. 

Payload  Failure  Propagation  and  Fault  Tolerance 
(3.3.8) 

Ensure  that  propagating  faults  by  the  Payload  are 
identified  to  the  Host  for  mitigation  and  the  identified 
propagating  faults  from  the  Host  are  mitigated  by  the 
Payload. 

Interface  Electrical  Worst  Case  Analysis  (3.3.9) 

Ensure  that  the  interfaces  will  operate  over  all 
intended  temperatures,  radiation  levels,  initial 
tolerance  and  aging  effects.  Include  derating  of  EEE 
components  for  reliability/design  margin  and 
successful  operation  during  transient  conditions. 

Interface  Timing  (3.3.10) 

Ensure  digital  signals  can  communicate  in  worst- 
case  expected  conditions. 

Single  Event  Effect  (SEE)  Evaluation  (3.3.1 1 ) 

Ensure  that  semiconductor  devices  comply  with  the 
SEE  destructive  and  SEU  requirements  in  their 
required  circuit  applications. 

Hazard,  Failsafe  and  Launch  Safety  Evaluation 
(3.3.12) 

Ensure  that  the  combined  design  including  fail-safe 
features,  preventing  premature  operation,  complies 
with  the  range  safety  features. 

Mechanical  and  Fatigue  Analysis  (3.3.13) 

When  applicable,  perform  these  analyses  to  verify 
that  performance  over  mission  life  can  be  met  with 
margin.  As  an  example,  the  resulting  mechanical 
fatigue  from  thermal-cycling  is  a  factor  that  should  be 
considered. 

Test  Like  You  Fly  (3.4.1) 

Ensures  that  the  Payload  and  Host  can  perform  as 
intended  over  all  phases  of  the  mission. 

3.3.5  Reliability/Redundancy 

During  preliminary  analyses,  the  interfaces  should  be  evaluated  to  verify  that  redundancy  is  compatible 
between  the  Payload  and  Host  Space  Vehicle,  and  that  any  required  probabilities  of  success  are  met  for 
the  combined  system.  Additional  reliability  considerations  are  provided  in  the  checklists  in  Appendix  A. 

3.3.6  Single  Point  Failure  Evaluation 

Failure  modes,  effects  and  criticality  analyses  (FMECAs)  are  performed  to  identify  and  rank  the  severity 
of  failures.  The  results  of  FMECAs  should  include  identification  of  failure  effects  that  are  deemed 
unacceptable,  and  require  design  mitigation.  Redundancy  should  be  used  to  eliminate  Single  Point  Failure 
Items  when  possible  and  practical.  In  cases  where  design  redundancy  is  not  feasible,  rationale  is  required 
to  justify  retention  of  the  failure  mode.  The  most  severe  failure  effects  that  are  not  corrected  (loss  or 
significant  degradation  of  mission)  should  be  documented  in  a  Single  Point  Failure  Item  List,  with  this 
justification,  for  review  by  customers  and  insurance  underwriters. 
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Failure  modes  can  be  subtle,  insidious,  and  severe.  To  be  effective,  failure  modes  and  failure  effects 
should  be  analyzed  from  each  side  of  the  interface  between  Host  and  Payload,  and  results  discussed  and 
resolved  cooperatively. 

3.3.7  Host  Failure  Propagation  and  Fault  Tolerance 

Although  failure  propagation  from  the  Payload  to  the  Host  is  of  primary  concern,  the  reverse  path  should 
be  addressed  as  well.  There  could  be  instances,  such  as  “unintended  commands”  from  the  Host,  that  can 
affect  the  Payload  as  well  as  the  Host. 

A  list  of  potentially  propagating  failures  can  be  generated  by  performing  an  FMECA  to  some  depth  on  the 
Host-to-Payload  interfaces.  That  list  should  be  provided  to  the  Payload  so  it  may  ensure  appropriate 
robustness  against  these  failure  modes. 

An  FMECA  format  that  addresses  both  propagating  failures  from  the  Host  and  the  effect  of  Payload 
failures  on  the  host  is  shown  in  Appendix  B.  A  propagating  failure  list  generated  from  this  FMECA  is 
also  included  in  this  appendix. 

Since  the  Host  and  its  primary  mission  payloads  have  top  priority,  failure  mitigation  at  this  interface  must 
be  provided.  Protection  of  the  Host  power  bus  from  failure  has  the  highest  priority.  Fusing  of  loads  (such 
as  the  Host  subsystems,  and  Payloads),  is  designed  to  prevent  single  point  “mission  ending  failures”  from 
failure  modes,  such  as  “shorts  to  ground”. 

Autonomous  under-voltage  detection  and  disconnect  of  “non-essential  loads”  is  another  “fail-safe” 
feature  for  protecting  the  Host  power  bus.  Relay  disconnect  of  smart  shorts  has  also  been  included  in 
design  architectures  for  providing  complete  isolation  and  removing  these  faults  that  are  insufficient  to 
“clear  a  fuse”,  but  continue  as  power  consuming  loads.  Capacitive  bypass  circuits  across  relay  contacts 
can  provide  protection  from  welding  during  “hot  switching.”  Current-limiting  designs  may  also  be  used  to 
reduce  in-rush  current  while  charging  input  capacitor  hanks  of  Payloads  during  power-on,  prior  to 
activating  a  Payload  DC  converter. 

There  are  no  established  and  published  ground  rules  for  performing  a  fault  tolerance  analysis,  but 
potential  faults  could  be  identified  by  performing  an  FMECA  on  the  host  side  considering  a  list  of 
propagating  failure  modes  provided  by  the  Payload. 

3.3.8  Payload  Failure  Propagation  and  Fault  Tolerance 

Exceipts  from  a  preliminary  Payload  FMECA  and  the  resulting  Propagating  Failure  Item  List  are  also 
shown  for  a  hypothetical  Payload  preliminary  analysis  in  Appendix  B.  It  is  expected  that  most 
experienced  space  contractors  will  have  similar  formats  that  they  can  adapt  for  the  purpose.  The  only 
thing  unique  about  this  approach  is  evaluation  from  both  directions. 

Though  considered  lower  in  importance  than  the  Host  and  its  primary  mission,  the  Payload  will  typically 
be  expensive  and  valuable  in  its  own  right.  Fault  tolerance  should  be  evaluated  in  a  manner  similar  to  the 
Host,  with  the  Host  providing  a  list  of  potential  propagating  failures  to  the  Payload. 


3.3.9  Interface  Worst  Case  and  Steady  State  Electrical  Stress  Analysis 

Worst  Case  Circuit  Analyses  (WCCA)  ensure  adequate  performance  margin  under  worst-case  conditions. 
They  consider  initial  temperature  extremes,  input  voltage,  part  parameter  variations,  tolerance,  and 
radiation  degradation  over  the  intended  life.  These  are  normally  required  for  operational  missions  and 
payloads. 
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For  Payload  projects,  analysis  from  the  perspective  of  the  Payload  and  the  Host  is  important,  since 
variations  on  one  side  of  the  interface  can  affect  performance  on  the  other.  It  is  not  uncommon  for  the 
Payload  to  have  a  shorter  design  life  than  the  Host  so,  unless  the  Payload  will  be  completely  isolated  from 
the  Host  at  the  end  of  life,  interfaces  would  require  analysis  for  the  entire  Host  mission  duration. 

However,  a  premature  Payload  failure  must  be  considered  and  the  required  electrical  isolation  provided  to 
prevent  failure  effects  on  the  Host.  Survival  heaters  by  the  Host  should  be  designed  to  be  energized  as 
required  with  loss  of  input  power  from  the  Host  to  the  Payload. 

There  are  many  documents  describing  WCCA,  and  many  formats  are  used.  It  would  probably  be  best  if 
the  Host  took  the  lead  in  performing  and  documenting  this  analysis  with  the  Payload  provider. 

The  WCCA  should  be  updated  if  the  performance  requirements  of  individual  parts  or  devices  do  not  meet 
their  requirements  or  have  “out  of  family”  characteristics  during  subsequent  lot  screening  tests.  As  an 
example,  a  Host  had  1553  prime  and  redundant  buses  connected  to  those  of  the  payloads  with 
transformers.  The  leakage  inductance  of  these  transformers,  based  upon  the  results  of  a  lot  screening  test, 
was  “out  of  family”.  Because  of  potential  over-stress,  identified  by  the  updated  WCC  A  for  the  input 
ASIC  (Application  Specific  Integrated  Circuit)  in  the  Payload,  a  life  test  was  performed  on  the  input 
ASIC  to  verify  that  mission  life  requirements  were  met. 

Steady-state  electrical  stress  analysis  is  performed  to  ensure  electrical  components  have  stresses  well 
within  their  capabilities  over  operating  temperatures,  so  their  failure  rates  remain  low.  This  analysis  also 
verifies  that  part  manufacturer’s  ratings  are  not  exceeded  even  during  worst-case  transients.  Examples 
might  include  inrush  currents  into  tantalum  capacitors. 

Documented  stress  analysis  of  an  operational  Payload  and  its  interfaces,  correlating  inputs  and  outputs  to 
those  of  the  Host,  is  expected. 

Lower  class  Payloads  may  elect  to  avoid  detailed  stress  analysis  on  their  internal  circuitry  to  reduce  cost, 
or  because  they  use  existing  off-the-shelf  designs  that  will  be  validated  by  other  means.  Still,  any 
interfaces  that  play  an  active  role  with  Host  electronics  in  a  non-mitigated  fashion  should  have  the  same 
level  of  scrutiny  as  those  of  the  Host.  Examples  might  include  1553  transceivers  on  a  shared  data  bus, 
receivers  of  RS422  pulses  from  the  host  and  survival  heaters  powered  by  the  Host. 

3.3.10  Interface  Timing 

An  interface  timing  analysis  is  performed  to  verify  that  digital  communications  margins  are  met  under  the 
same  conditions  as  the  WCCA.  Potential  sources  of  “race  conditions”  can  be  identified  and  corrected.  The 
analysis  should  be  updated  as  needed  with  subsequent  “out  of  family  device  performance”  based  upon 
any  adverse  results  from  lot  screening. 

There  is  no  standard  format  for  these  analyses,  but  they  are  performed  industry-wide.  The  Host  should 
initiate  timing  analyses  as  needed.  Rise  and  fall  times  and  pulse  polarity  could  fall  under  either  timing  or 
worst  case  analysis. 

3.3.11  Single  Event  Effect  Evaluation 

Single  event  effects  and  potential  latch-ups  within  the  Host  are  analyzed  by  the  Host  to  ensure  appropriate 
availability  and  robustness  are  achieved.  Those  within  the  Payload  should  be  analyzed  for  the  same 
purpose. 

It  is  important  that  no  circuitry  susceptible  to  permanent  latch-up  be  present  at  the  interfaces,  and  that  the 
rates  and  effects  of  SEEs  on  interfacing  circuitry  be  identified  by  the  Payload  and  Host  so  that  any  effects 
that  can  occur  on  one  side  of  the  interface  are  either  mitigated  or  accepted  by  the  other. 
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3.3.12  Hazard,  Fail-Safe  and  Launch  Safety  Evaluation 

Delivery  of  proper  documentation  and  analyses  to  the  Range  is  the  responsibility  of  the  Host.  Fail-safe 
features  and  interlocks  associated  with  the  Hosted  Payload  might  fall  fully  on  the  Host  side  of  the 
interface,  but  it  is  the  Host’s  responsibility  to  ensure  that  it  includes  any  necessary  input  from  the  Payload 
for  inclusion  in  the  Range  Safety  documentation  (e.g.,  Missile  System  Prelaunch  Safety  Package 
(MSPSP)). 

3.3.13  Mechanical  and  Fatigue  Analysis 

When  relevant  to  the  interfaces  involved,  additional  analyses  may  be  required.  Fatigue  analysis 
for  interfaces  with  thermal  mismatches  might  be  one  example.  Each  design  should  be  evaluated 
to  determine  what  additional  analyses  might  be  required. 

3.3.14  Program  Deliverables 

Data  and  other  analyses  that  might  be  required  in  addition  to  those  analyses  listed  earlier  in  this  section 
are  provided  in  Table  6. 

An  “X”  or  “O”  in  a  column  indicates  that  the  information  will  be  delivered  by  the  owner  of  that  column. 
An  “X”  in  a  column  indicates  a  need  to  share  is  perceived.  Blank  indicates  no  need  to  share  is  perceived. 
An  “O”  indicates  it  is  optional,  depending  on  the  specific  mission.  For  example,  sensitive  optics  on  a 
Payload  necessitate  assurances  that  the  Payload  will  not  be  contaminated.  Methods  to  accommodate  a 
contamination  sensitive  payload  might  be  shared  between  Host  and  Payload,  or  might  be  implemented 
primarily  by  one  or  the  other  as  negotiated  before  program  implementation. 

Each  Payload  project  would  develop  a  deliverables  list  appropriate  to  the  program.  Also  provided  is  the 
recommended  phase  that  this  information  be  available.  It  is  recognized  that  if  the  Host  and  Payload  are  on 
different  development  cycles,  the  deliverable  may  not  be  available  at  the  recommended  time.  Identifying 
and  addressing  these  phase  disconnects  should  be  part  of  the  risk  management  effort  for  the  program. 
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Table  6.  Suggested  Deliverables  List 


Deliverable 

Host 

Payload 

Comments 

Suggested 

Phase/timing 

Environmental 

requirements 

X 

Baseline  for  negotiation  and  subsequent  design 

Pre-award 

Interface 

requirements 

X 

Baseline  for  negotiation  and  subsequent  design 

Pre-award 

ICD  Information 

X 

Phased  footprint,  mass,  power,  dissipation, 
finish,  heat  flux  information,  connectors  and  pin¬ 
outs 

Start  information 
flow  at  award 

Command  formats 

X 

X 

For  mutual  evaluation 

Pre  PDR 

Telemetry  formats 

X 

X 

For  mutual  evaluation 

Pre  PDR 

Materials  Lists 

0 

X 

For  contamination  evaluation 

Pre  PDR,  Updated 
at  PDR,  Final  at 
sell-off 

Parts  Lists 

X 

For  approval  of  any  non-Space  rated  parts 

Pre-PDR 

Functional  Block 
Diagrams 

X 

X 

For  understanding  and  planning 

Pre  PDR 

Operational 

Description 

X 

X 

For  ConOps  planning 

Pre  PDR 

Interface  schematics 

X 

X 

For  mutual  evaluation 

Post  PDR 

Industrial  Health  and 
Safety  Information 

X 

Any  integration  and  test  hazard  related 
information 

Post  PDR 

Waivers,  e.g. 
prohibited  materials 

X 

Passed  to  Host  operator  for  mission  insurance 
documentation  purposes 

As  encountered 

Range  Safety 
Information 

0 

X 

Should  be  provided  in  some  detail  early  to 
ensure  launch  base  compatibility 

Post  PDR, 

Final  for  launch 
submittal 

Hazard  Analyses 

X 

For  range  safety 

Per  schedule 

Orbital  Debris 
Assessment 

X 

US  or  NASA  standards 

Per  schedule 

End  Item  Data 
Packages 

X 

Due  diligence  for  insurance 

As  produced,  e.g. 
at  pre-ship  review 

Emulators  and 
Simulators 

X 

X 

Host  and  payload  emulators  for  risk  reduction 
test  before  payload  delivery 

Unique  for  each 
program 

Electrical  and 
Mechanical  Ground 
Equipment 

X 

X 

Handling,  installation  and  offloading  equipment 

Unique  for  each 
program 

Anomaly  and  non¬ 
conformance  reports 

X 

X 

For  class-1  interface  anomalies 

As  identified 

Test  plans  and 
procedures 

X 

X 

For  tests  to  verify  performance  and  interfaces 

Prior  to  test 

3.3.15  Aspects  of  On-orbit  Fault  Detection  and  Mitigation 

The  Host  will  have  established  fault  detection,  identification,  and  recovery  practices  for  its  bus  and 
primary  mission  to  respond  to  expected  contingencies  such  as  loss  of  attitude  stabilization  and  resulting 
decrease  in  available  power.  To  ensure  there  is  no  risk  to  the  primary  mission,  a  Payload  will  be  one  of 
the  first  loads  shed  during  such  a  contingency.  It  must  be  able  to  tolerate  rapid  shutdown  via  removal  of 
Host-supplied  power  with  or  without  warning. 

During  significant  on-orbit  anomalies,  Hosted  and  Primary  Communication  Payloads  are  expected  to 
cease  transmissions  to  avoid  interference  with  and  potential  damage  to  adjacent  spacecraft  and  on-ground 
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receiving  facilities.  If  a  graceful  shutdown  is  desired,  then  programmed  commands  to  cease  transmissions 
and  power  down  should  be  provided  for  incorporation  into  on-board  software,  scripts,  or  command 
queues.  Function  of  these  shutdown  processes  should  be  verified  during  system  level  test,  before  launch. 

During  transition  of  the  Host  to  a  safe  mode,  the  optical  or  RF  apertures,  or  thermal  radiators,  could 
experience  direct  sunlight,  prolonged  eclipse-like  conditions,  solar  reflections  or  exposure  to  uplink 
signals.  Unless  the  Host  can,  with  a  high  level  of  confidence,  avoid  these  exposures,  the  Payload  should 
provide  its  own  protection  from  these  conditions. 

These  same  possibilities  are  expected  to  be  present  during  all  phases  of  the  mission  including  during 
launch,  in  drift  orbits,  during  In  Orbit  Test  (IOT)  and  during  mode  transitions.  This  would  also  be 
applicable  to  expected  contingencies  such  as  loss  of  lock  or  other  detected  faults. 

If  the  Payload  includes  fault  detection,  identification,  and  recovery  practices,  these  practices  should  be 
evaluated  for  potential  risk  to  the  Host  (e.g.  unexpected  power  draw  and  subsequent  torque  to  close 
covers). 

3.4  Verification  and  Test 
3.4.1  System  Test: 

If  Payload  and  Host  schedules  are  compatible,  and  the  Payload  is  available  for  installation  at  one  of  the 
preferred  insertion  points,  then  system  level  testing  can  proceed  according  to  the  usual  spacecraft  test 
process.  Typically,  this  will  verify  mechanical,  electrical,  thermal,  and  software  interface  compatibility. 

Manufacturers  (Hosts)  will  differ  in  their  approach,  but  a  general  approach  is  to  test  in  the  sequence  in 
which  the  mission  is  ordered  (“Test  Like  You  Fly”).  Key  test  phases  include  those  listed  below,  though 
some  may  be  considered  qualification  tests,  and  may  not  be  repeated  for  heritage  Host  missions.  The  Test 
Like  You  Fly  process  can  be  implemented  in  a  rigorous  fashion  by  following  Reference  12.  Alternatively, 
an  established  Host  test  program  might  be  analyzed  to  ensure  special  modes  and  scenarios  introduced 
with  insertion  of  the  Payload  are  tested  in  a  flight-representative  manner. 

•  Bonding  and  Grounding  checks 

•  ESD  testing 

•  Acoustic  and  Sine  Vibration  Test 

•  Separation  Shock  Testing 

•  Deployment  Shock  Testing 

•  Baseline  Functional  Testing  and/or  Pre-Thermal  Vacuum  test 

•  Thermal  Vacuum  Test 

•  Antenna  Test  Range  for  Pattern  and  Isolation  Verification 

•  EMI  and  EMC  testing 

•  Final  Functional/Post  Environmental  Test 

Performance  of  these  system  tests  verifies,  with  margin,  the  capability  of  the  integrated  Host  and  Payload 
to  survive  the  launch  environment  without  inducing  damage  to  each  other.  It  also  verifies  they  will 
operate  in  a  compatible  manner,  without  interference. 
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If,  for  any  reason,  the  Payload  is  not  available  for  any  of  these  verification  tests  then  a  condition  of  risk 
exists.  Compatibility  has  not  been  verified.  This  possibility  should  be  recognized  early  in  the  project,  and 
appropriate  mitigating  actions  applied.  Mitigating  actions  might  be  additional  analyses,  or  test  with 
emulators,  simulators,  or  engineering  model  structures. 

Fault  testing  and  simulation  should  be  addressed  to  the  greatest  extent  practical.  Functional  test  of  all 
operational  and  contingency  modes  is  essential.  Practicing  of  contingency  procedures  during  launch/IOT 
rehearsals  and  operational  training  is  recommended.  Payload  behavior  should  be  planned  for  actuation  of, 
transition  to,  and  survival  in  all  Host  safe  modes. 

3.4.2  Verification 

Verification  is  the  process  for  ensuring  that  the  final  design  meets  its  requirements.  In  this  case,  we  are 
concerned  about  whether  the  Host  and  Payload  designs  meet  the  requirements  for  their  shared  interface. 
The  set  of  critical  requirements  for  a  hosted  payload  will  be  developed  and  negotiated  between  the  Host 
and  Payload  and  should  be  documented  in  an  Interface  Control  Document,  a  Requirements  Document,  or 
a  similar  set  of  documents.  Not  all  requirements  for  a  Payload  are  needed  in  such  a  document,  but  those 
related  to  interfaces  and  properties  that  are  necessary  for  Host  compatibility,  including  its  launch  and 
operation,  are  considered  necessary.  Many  of  those  considerations  are  addressed  elsewhere  in  this  TOR. 

Requirements  should  be  developed  as  verifiable  statements.  Vague  or  non-specific  requirements  leave 
too  much  open  to  interpretation.  Verification  requirements  should  also  be  specified  in  the  requirements 
document.  At  a  minimum,  verification  requirements  should  include  the  required  assembly  level  and 
method  for  verifying  each  technical  requirement.  Industry  practice  is  to  verify  requirements  by  Analysis, 
Test,  Inspection,  or  Demonstration. 

Verification  planning  and  definition  of  methods  should  be  established  early  in  the  program  to  ensure  there 
are  no  unverified  requirements  at  the  end.  A  typical  approach  to  verification  planning  starts  with  creating 
a  requirements  verification  matrix  that  defines  the  verification  approach  and  pass/fail  criteria. 

The  space  industry  has  developed  standards  by  which  all  contractors  follow  consistent  practices  for 
verifying  and  testing  space  products.  These  standards  are  explained  in  detail  in  references  such  as 
TOR-2006(8506)-4732  Space  System  Verification  Program  and  Management  Process,  MIT  .-STD- 1 540 
Test  Requirements  for  Launch,  Upper-stage,  and  Space  Vehicles,  and  TOR-2004(8583),  Test 
Requirements  for  Space  Vehicles.  A  delta-qualification  review  may  be  necessary  to  ensure  that  the 
Hosted  Payload  is  qualified  to  operate  in  the  mission  environment  of  the  Host. 

As  programs  mature,  verification  details  should  be  updated  and  reviewed  at  key  milestones.  As  each 
verification  event  is  completed  the  verification  matrix  is  updated  to  show  the  results  and  compliance.  For 
parametric  properties  the  matrix  should  incorporate  predicted  values,  then  values  verified  by  test.  Any 
differences  between  the  requirements  and  actual  properties  that  are  uncovered  during  the  program  should 
be  addressed  using  Waiver,  Deviation,  or  Nonconformance  processes  to  determine  their  acceptability. 

3.4.3  Risk  Reduction/Payload  Acceptance  Test: 

System  test  effectively  validates  the  intended  mission  performance.  Lower  level  interface  testing  is 
performed  to  reduce  the  risk  of  discovering  incompatibilities  and  failures  at  the  system  level. 

Testing  with  the  actual  Host  interfaces  is  ideal.  Testing  of  engineering  model  or  brassboard  Payload 
equipment  on  a  Host  test  bed,  if  possible,  is  a  good  method  of  risk  reduction.  The  possibility  that  mockup 
circuits,  or  Host  engineering,  or  qualification  models  might  be  made  available  for  this  testing  should  be 
explored. 
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Acceptance  testing  of  Payloads  and  their  equipment  should  be  performed  to  industry  norms  to  ensure  no 
design  deficiency  or  random  defect  will  jeopardize  the  mission  of  either  the  Host  or  Payload. 

The  order  of  tests  can  vary,  but  will  generally  include  the  following. 

•  Baseline  Electrical 

•  Non-operational  Thermal  Cycling 

•  Shock  (typically  only  for  qualification  test) 

•  Sine  Vibration 

•  Random  or  Acoustic  Vibration 

•  Thermal  Vacuum  Test,  with  measurements  at  nominal  and  extreme  temperatures 

•  ESD  testing  (typically  only  for  qualification  test) 

•  EMI/EMC  testing 

•  Final  Functional  Test 

Additional  testing  specific  to  the  system  under  consideration  may  be  useful  to  further  reduce  system  test 
risk. 

3.4.4  Verification  of  Mixed  Class  Missions 

Hosted  payloads  may  be  of  lower  quality  than  the  operational  missions  that  host  them.  Government 
programs,  for  example,  are  classified  by  level,  with  Class  A  being  an  operational  mission  with  all 
assurance  practices  applied.  Lower  classes  may  be  pathfinders,  experiments,  or  concept  verification 
projects.  Operational  commercial  spacecraft  use  high  quality  components  with  thorough  analysis  and  test. 
They  are  analogous  to  government  Class  A  missions,  though  they  typically  use  only  high  Technology 
Readiness  Level  equipment  to  reduce  technical  and  schedule  risk. 

Lower  classes,  such  as  Class  D,  may  use  COTS  units  made  using  lower  quality  parts  and  without  the 
control  over  materials  and  processes  expected  of  operational  flight  products.  This  could  be  considered  a 
gap  in  requirement  levels.  Test  rather  than  analysis  may  be  the  only  way  to  ensure  compatibility  in  certain 
respects. 

It  is  important  to  note  that  regardless  of  the  class  designation  of  the  Payload,  the  class  of  the  Host  will 
drive  the  relative  class  of  the  Payload  to  Host  interfaces.  Thus,  in  the  case  of  the  typical  GEO  commercial 
communications  spacecraft,  which  is  insured  for  a  15+  year  primary  mission,  the  Host  is  considered  Class 
A  and  demands  Class  A  Payload  interfaces  and  verification. 

Risk  reduction  evaluation  tests  to  verify  the  capability  of  units  proposed  for  use  on  an  operational  mission 
should  be  performed  early  in  the  Payload  design  phase.  An  example  test  would  be  for  condensable 
volatiles  if  COTS  components  are  included  in  the  payload  design.  Lower  class  verification  methodologies 
will  need  to  be  accepted  by  the  Host  and  Operator  as  part  of  the  Mission  Assurance  and  Systems 
Engineering  processes. 

Higher  class  operational  Hosted  Payloads  that  incoiporate  internal  redundancy  may  expect  robust  and 
redundant  interfacing  support  equipment  from  the  Host.  Lower  class  missions  might  require  less  support 
in  accordance  with  their  lower  cost  approaches.  As  an  example,  a  single-thread  (no  redundancy)  Class  D 
mission  might  not  require  redundant  command  or  power  from  the  Host,  while  an  operational  Class  A 
payload  would. 
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4.  Summary,  Findings,  Conclusions,  and  Recommendations 


During  the  development  of  this  document,  team  members  shared  their  personal  and  company  experiences, 
conducted  interviews,  and  researched  publications  on  hosted  payload  projects.  The  compiled  information 
seemed  to  reveal  patterns  worth  emphasizing. 

Common  themes  increasing  risk  included  insufficient  information  sharing  between  Host  and  Payload; 
lack  of  knowledge  of  Host  requirements,  configuration,  con-ops  and  environments  during  Payload 
development;  and  lack  of  direct  involvement  between  Host  and  Payload  during  technical  planning. 

Key  recommendations  and  thoughts  from  the  team  include: 

•  Host  and  Payload  providers  should  define  their  roles  and  responsibilities  as  early  as  possible. 

•  Payload  equipment  providers  and  the  Host  should  interact  directly  and  frequently. 

•  A  system-level  gap  analysis  should  be  performed  by  the  Host  and  Payload  teams  at  program 
inception  to  identify  disconnects  and  plan  accommodation. 

•  Open  communication  channels  should  be  established  between  Host  and  Payload  specialists,  so 
that  models  and  interfaces  designs  can  be  exchanged  and  negotiated. 

•  Standards  and  definitions  should  be  agreed  upon  at  program  inception. 

•  Simulators  and  emulators  should  be  used  prior  to  payload  integration  to  reduce  interface  risk. 

•  Payload  providers  should  support  system-level  test  planning  and  testing  at  the  Host  facility. 

•  Payloads  should  be  tested  realistically  with  the  Host  after  systems  integration. 

The  authors  and  reviewers  of  this  document  strongly  recommend  that  potential  Hosts  publish  and 
distribute  environmental  and  interface  requirements  and  that  potential  Payloads  review  and  consider  these 
at  the  earliest  practical  phase  of  development 

Table  7  lists  some  of  the  difficulties  that  were  experienced,  with  likely  root  causes  and  steps  that  might 
have  resulted  in  avoidance  of  the  problem. 
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Table  7.  Experiences  on  Hosted  Payload  Projects 


Phenomenon 

Likely  cause 

Mitigation 

Gain  ripple  in  a  hosted  payload  signal  due  to 
interference  between  the  hosted  payload  and  its  back 
lobes  reflecting  from  primary  payload  structure. 

Hosted  payload  not  tested  with  an 
assembled  spacecraft  in  the  system  level 
antenna  test. 

Test  like  you  fly  whenever  possible.  If  this  cannot  be 
done,  the  off-nominal  test  sequence  should  be  elevated 
and  tracked  as  part  of  the  risk  management  process. 

Instrument  baffle  had  to  be  trimmed  due  to  physical 
interference  with  deployed  appendage. 

Inadequate  exchange  of  configuration 
information. 

Early  exchange  of  physical  model  (e.g.,  Pro-E)  data. 

Hosted  payload  tested  in  excess  of  its  thermal 
capabilities  after  installation  onto  the  host. 

Host  personnel  unaware  of  Payload 
limitations. 

Participation  of  Payload  personnel  in  test  design  and 
system  test  with  host. 

Outgassing  of  chamber  damaged  Payload  optics. 

Lack  of  communication  and  verification 
between  host  and  payload. 

Participation  of  Payload  personnel  in  test  design  and 
system  test  with  host. 

Payload  survival  heaters  were  not  powered  during 

T/V  testing. 

Lack  of  communication  and  verification 
between  host  and  payload. 

Participation  of  Payload  personnel  in  test  design  and 
system  test  with  host. 

Lack  of  clear  requirements  and  baseline  caused 
numerous  design  iterations  and  “scope”  claims. 

Insufficient  definition  of  requirements. 

Clear  standard  requirements  up  front. 

Power  on  transients  were  encountered  when  mating 
up  a  payload  with  the  host. 

Transients  were  not  specified  by  host,  and 
current  limit  style  was  not  communicated. 

Design  details  should  be  shared  early  and  interfaces 
tested  early. 

A  significant  redesign  was  needed  because  of 
clearance  and  routing  interferences. 

Volume  envelope  did  not  account  for 
variability  and  intrusions. 

Work  together  to  fully  understand  volume  limitations 
including  screw  heads,  wiring  and  cabling,  gaskets, 
dynamic  displacement,  multi-layer  insulation,  and 
tolerance  stack-up. 

Host  venting  paths  distributed  contamination  into 
Payload  optical  cavity. 

Insufficient  cooperative  design  of 
contamination  prevention  program. 

A  careful  contamination  control  program  should  be 
developed  whenever  there  are  contamination  sensitive 
components  on  the  Host  or  Payload. 

Payload  units  qualified  to  dynamic  load  levels  per 
existing  noncommercial  (NASA  GEVS)  standards, 
insufficient  to  meet  commercial  geosynchronous  load 
levels. 

Lack  of  awareness  of  commercial 
requirements  differing  from  NASA,  due  to 
use  of  a  wider  range  of  Launch  Vehicles,  for 
example. 

Detailed  dynamic  load  “gaps”  comparison  performed  as 
early  as  possible  to  ensure  compatibility.  Loads  analysis 
performed  and  risk  mitigation  plan  put  in  place  if  Host 
and  Payload  requirements  contain  “gaps.” 
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Appendix  A.  Checklists 


The  checklists  provided  here  are  intended  to  help  spur  the  thought  process  throughout  a  payload 
project.  They  are  based  on  the  experiences  of  individuals  in  our  group  and  of  their  companies.  They 
do  not  provide  a  cookbook  for  hosting  payloads,  nor  should  they  be  considered  a  replacement  for  the 
Systems  Engineering  process  that  is  required  to  appropriately  host  a  payload.  In  the  initial  phase  of 
Payload  accommodation  the  Host  and  the  Payload  Provider  need  to  apportion  responsibilities  for 
these  checklist  items. 

Line  items  are  numbered  sequentially  in  each  discipline,  with  leading  abbreviations  as  shown  in 
Table  12. 


Table  8.  Key  to  Areas  of  Expertise 


AC 

Attitude  and  Orbit  Control 

CD 

Command  and  Data  Handling 

CM 

Configuration  Management 

CC 

Contamination  Control 

El 

Electrical  Interface  Design  and  Integration 

EM 

EMI/EMC 

FM 

Fault  Management 

MP 

Materials  and  Processes 

Ml 

Mechanical  Layout  and  Integration 

OP 

Optics 

PW 

Power 

SR 

Safety,  Reliability/FMECA 

SM 

Structural,  Mechanical,  Alignments  and  Mass  Properties 

TH 

Thermal 

Table  9.  Additional  Reference  Documents  for  Appendix  A 


Title 

Document 

Function 

A1 

Electromagnetic  Compatibility 
Requirements  for  Space  Systems 

MIL-STD-1541 

Establishes  EMC  requirements 
for  space  systems. 

A2 

Space  Power  Standard 

SAE  AS5698 

This  standard  defines  the 
requirements  and 
characteristics  of  electrical 
power  for  spacecraft.  It  also 
defines  analysis,  verification, 
and  testing  methodologies. 

A3 

Technical  Requirements  for 

Electronic  Parts,  Materials,  and 
Processes  Used  in  Space  Vehicles 

Aerospace  Report  TOR- 
2006  (8583)-5236 

Establishes  the  minimum 
technical  requirements  for 
electronic  parts,  materials,  and 
processes. 

A4 

Instructions  for  EEE  Parts  Selection, 
Screening,  Qualification,  and 

Derating 

NASA/TP-2003-212242; 

EEE-INST-002 

Establishes  baseline  criteria 
for  selection,  screening, 
qualification,  and  derating  of 

EEE  parts  on  space  flight 
projects. 

A-l 


Attitude  Control 


Attitude  Control,  pointing,  and  orbit  determination  are  related  topics  from  a  Payload  point  of  view.  Payload  designs  that  require  pointing 
control  will  depend  at  least  in  part  on  the  Host  for  assistance  on  meeting  pointing  performance.  Note  that  any  change  to  the  normal  Host 
ConOps  to  accommodate  the  Payload  may  influence  both  the  Host  design  and  the  Owner/Operator’s  mission  operations  resources. 
Additionally,  incorporation  of  the  Payload  should  not  degrade  the  Host's  pointing  and  attitude  control  performance  such  that  primary  mission 
objectives  are  not  met.  The  following  items  should  be  considered  when  evaluating  the  feasibility  of  the  Payload  accommodation. 

Table  10.  Attitude  Control  Checklist 


Item 

Topic 

Consideration 

Comments 

AC1 

Pointing 

Pointing  requirements. 

The  pointing  requirements  will  be 
driven  by  the  payload  with  the  tightest 
requirements  (Primary  or  secondary). 

AC2 

Disturbance/Jitter 

Disturbances  generated  by  the  host  at  the  payload  interface 
(rotational  and  translational  amplitude  and  frequency  content). 

Structural  dynamics  are  a  significant 
factor  in  the  pointing  budget. 

AC  3 

Disturbance/Jitter 

Disturbances  generated  by  the  payload  at  the  payload  interface 
(uncompensated  momentum,  torque  and  jitter  amplitude  and 
frequency  content). 

Payload  should  compensate  for,  or 
be  able  to  tolerate,  any  moving 
masses  required  during  operation. 

AC4 

Knowledge 

Requirements 

Host  ephemeris  and  attitude  knowledge  (position  and  rate; 
accuracy;  update  rate  and  latency)  should  be  defined  in  ICD. 

Is  this  data  required  for  payload 
ConOps?  Is  this  data  required  for  on¬ 
board  or  for  ground  processing? 

AC  5 

Host  Maneuvers 

Spacecraft  Maneuvers  (Delta  V,  Momentum  dumps). 

ConOps  must  consider  if  payload  can 
meet  its  mission  during  maneuvers. 

If  it  cannot,  does  host  need  to  provide 
schedule  to  payload  or  create  special 
ConOps? 

AC  6 

ConOps 

The  host  Owner  Operator  should  coordinate  spacecraft 
maneuvers  with  the  Payload. 

The  degree  of  coordination  would 
normally  be  contractually  agreed  prior 
to  starting  the  project. 

AC7 

Payload  Field  of 

Regard 

Payload  field  of  regard  must  consider  Host  spacecraft  Agility. 

Is  payload  Field-of  Regard  and 
control  system  adequate  for  expected 
host  attitude  changes? 

AC  8 

Mass  Properties 

Payload  must  provide  mass,  center  of  gravity,  and  inertia  during 
all  mission  phases  for  attitude  control  use.  Does  payload 
deploy? 

If  payload  is  late,  will  a  mass 
simulator  be  required? 

A-2 


Item 

Topic 

Consideration 

Comments 

AC  9 

Orbits 

Payload  orbital  drag,  Center  of  Pressure  during  all  mission 
phases. 

Does  host  need  to  provide 
compensation  to  reduce  propellant 
usage? 

AC10 

Failure  Modes 

Can  Host  perform  mission  with  failed  Payload  deployment  (at 
any  point  in  deployment)? 

Will  the  failure  impact  primary 
mission?  Will  payload  meet 
frequency  requirements  with  failed 
latch-up? 

AC1 1 

Stability  Related 

Payload  Thermal  stability. 

Any  thermally  driven  disturbances. 

AC12 

Structure 

Payload  Structural  frequency. 

Is  payload  frequency  low  enough  to 
require  coupled  analysis? 

AC13 

Dynamic  Models 

Stiffness. 

Will  a  dynamic  model  be  needed  for 
coupled  analysis? 

AC14 

Nonlinear  Dynamics 

Payload  dynamics  nonlinearities. 

Payload  should  provide  nonlinear 
dynamics  behavior  to  Host  for  design 
of  the  control  system. 

AC15 

Coordinate  Reference 
Frames 

The  SC  contractor  and  Payload  Contractor(s)  shall  jointly  agree 
on  a  method  to  define  the  transformations  between  the  SC 

Attitude  Reference  Frame  and  the  Payload  Reference  Frame. 

Pointing,  knowledge,  and  mass 
properties  all  depend  on  axis 
definition. 

AC16 

Glint 

Is  payload  visible  to  any  ACS  sensors?  What  is  the  surface 
material?  Is  Host  visible  in  payload  Field  of  Regard? 

Stay-out  zones  for  payload  radiators, 
glint-free  zones,  and  other 
restrictions,  shall  also  be  specified  in 
the  ICD. 

AC17 

Payload  Safing 

Payload  Field  of  view  constraints  (Payload  safety). 

Must  payload  be  protected  from  sun 
or  earth  view  during  nominal 
operations  or  safe  mode  transitions? 

AC18 

Orbit  Limitations 

Payload  may  only  be  able  to  meet  Payload  mission  requirements 
in  certain  orbits  or  orbital  arcs/longitudes  due  to  RF  coverage, 
signal  strength,  line  of  sight,  power  or  thermal. 

Are  the  potential  Host  orbits  and 
tolerances  compatible  with  Payload 
orbit  constraints? 

AC19 

Payload  Safing 

Does  Host  need  to  provide  a  safing  command  to  payload  before 
orbital  maneuvers? 

A-3 


Command  and  Data  Handling 


Command  and  Data  Handling  includes  command  through  the  Host  to  the  Payload,  and  return  telemetry  that  might  be  routed  through  the  Host 
C&DH  subsystem.  Telemetry  and  information  might  also  be  delivered  directly  to  the  ground  by  a  hosted  payload  if  Host  on-board  processing 
does  not  have  sufficient  bandwidth  for  the  task. 

Table  1 1 .  Command  and  Data  Handling  Checklist 


Item 

Topic 

Consideration 

Comments 

CD1 

Links 

Does  payload  have  its  own  ground  links? 

CD2 

Margin 

In  budgeted  items,  is  there  enough  contingency/margin  for  growth 
based  on  design  phase? 

Do  host  and  payload  use  the  same 
definition  of  “Contingency”  and 
“Margin”? 

CD3 

Data  Storage 

Is  storage  onboard  the  Host  required?  Is  it  partitioned  or  shared? 

Shared  memory  requires  higher  levels 
of  testing  to  assure  no  impact. 

CD4 

Data  Storage 

Is  storage  margin  enough  to  upload  payload  SW  updates? 

Future  SW  updates  can  be 
overlooked. 

CD5 

Data  Bus 

Is  encryption  of  payload  data,  telemetry  and/or  commands 
required? 

Who  is  responsible  for  encryption? 

What  encryption  protocols?  How  does 
this  influence  the  ground  system? 

CD6 

Telemetry  Dictionary 

Payload  Telemetry  dictionary  should  include:  data  type,  format, 
protocol  definition,  units,  expected  frequency. 

If  multiplexed,  payload  must  describe 
method  for  data  extraction. 

CD7 

Command  Dictionary 

Payload  Command  Dictionary  should  include:  purpose, 
preconditions,  restrictions  on  use,  format,  protocol  definition, 
command  arguments  and  data  types  (including  units). 

Must  include  nominal  and  off  nominal 

cases. 

CD8 

Error  Checking 

Does  payload  perform  any  error  checking  on  commands? 

If  error  checking  is  not  performed, 
procedural  methods  should  be 
employed  to  protect  payload. 

CD9 

Data  Format 

Payload  data  formatting  must  be  compatible  with  Host  data  bus. 

Host  must  provide  formatting 
requirements. 

CD10 

SOH  Telemetry 

Payload  should  provide  unencrypted  State  of  Health  telemetry. 

Prefer  at  all  time,  at  minimum  during 
anomaly. 

CD1 1 

Isolation 

Payload  telemetry  signals  must  have  failure  isolation. 

Consider  temperature  sensors  and 
housekeeping  data. 

CD12 

Processing 

Processing  margins  need  to  consider  all  modes  for  both  primary 
and  secondary  payloads. 

CD13 

Timing 

Accuracy,  stability  of  timing  signal. 

Can  be  an  issue  if  payload  has  tighter 
requirements  than  host.  Payload  may 
need  to  provide  own  timing. 

CD14 

Timing 

Do  payload  and  host  have  compatible  major/minor  cycles? 

CD15 

Fault  Detection 

Does  payload  perform  any  fault  detection? 

Consideration  for  fault  management 
design. 
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Item 

Topic 

Consideration 

Comments 

CD16 

Fault  Reporting 

Does  payload  perform  any  fault  reporting? 

Consideration  for  fault  management 
design. 

CD17 

Lock  Out  Preclusion 

Payload  must  be  precluded  from  locking  out  commanding. 

Host  may  need  to  reset  payload  in 
fault  situation. 

CD18 

Remote  Terminals 

Payload  remote  terminal  must  be  protected  so  that  it  cannot 
become  the  data  bus  controller. 

CD19 

Remote  Terminal 

In  fault  scenarios,  payload  RT  cannot  write  to  both  primary  and 
redundant  data  bus. 

CD20 

Remote  Terminal 

Is  Remote  Terminal  Addressing  fixed  or  reconfigurable? 

Failure  mode. 

CD21 

Contingency  Operations 

Payload  must  have  the  ability  to  inhibit  automatic  redundancy 
switching  (if  applicable). 

Automatic  switching  can  keep 
commands  from  getting  to  payload. 

CD22 

Modes 

Payload  should  provide  four  modes:  Operation,  Safe, 
Initialize/Standby,  Survival. 

Payload  may  have  several  sub-modes 
within  these  modes. 

CD23 

Contingency  modes 

In  all  modes  except  Operation,  payload  should  limit  data  to  that 
required  for  payload  health  and  status. 

CD24 

Safe  Mode 

Payload  should  not  inhibit  any  safe  mode  transition  whether  via 
command  from  Host  or  Ground  or  detection  of  internal  anomalies. 

Host  needs  ability  to  override  payload 
for  anomaly  response. 

CD25 

Operation  mode 

Payload  should  only  enter  operation  mode  upon  receipt  of  a  valid 
command  from  Host  or  Ground. 

CD26 

Fault  Protection 

Apply  independent  fault  protection,  such  as  hardware  watchdogs, 
to  mitigate  risk  in  real-time  systems. 

Errors  can  be  so  deeply  buried  as  to 
be  practically  undetectable. 

CD27 

End  of  Life  Plan 

Payload  should  place  itself  into  a  “safe”  configuration  upon 
reaching  its  end  of  life  to  prevent  damage  to  the  Host  Spacecraft 
or  any  other  payloads.  Payloads  often  have  shorter  missions  than 
their  Hosts. 

The  payload  may  have  potential 
energy  remaining  in  components  such 
as  pressure  vessels,  mechanisms, 
batteries,  and  capacitors,  from  which  a 
post-retirement  failure  might  cause 
damage  to  the  Spacecraft  Host  or  its 
payloads.  Safe  conditions  at  EOL 
should  consider  thermal  and  radiation 
environments. 

CD28 

Firing  and  Motor 

Circuits 

Protect  firing  circuits  against  sneak  currents  and  line-to-ground 
shorts. 

Components  such  as  step  motors  and 
pyro  circuits  that  experience  sudden 
current  changes  should  be  isolated 
from  all  other  current-carrying  circuits 
including  power,  control,  RF 
transmission  lines,  and  monitoring 
circuitry. 

CD29 

Testing 

Host  and  Payload  Test  Ports  should  be  separated  and  Isolated. 

Allows  easier  troubleshooting  during 
integration. 

CD30 

Interface  Compatibility 
Testing 

Hardware  and  software  compatibility  from  different  vendors  should 
be  verified  during  design. 

COTS  data  sheets  do  not  cover  all 
interface  parameters. 
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Configuration  Management 


A  cohesive  process  for  configuration  management  must  be  defined  so  that  both  the  Host  and  Payload  are  kept  current  with  critical  program 
information  affecting  both  parties.  Configuration  data  should  be  adequately  documented  and  archived  for  ease  of  reference  and  retrieval. 
Information  that  needs  to  be  exchanged  and  placed  under  the  common  configuration  management  process  should  be  defined  in  the  contract  or 
statement  of  work. 

Configuration  management  is  critical  for  capturing  changes  as  they  occur,  can  prevent  surprises,  and  optimize  performance  if  mutually 
beneficial  actions  are  implemented.  The  definition  of  a  mutually  beneficial  action  is  one  that  resolves  an  issue  for  one  or  both  missions  with 
minimal  cost  and  schedule  impact  to  either.  It  is  critical  that  impacts  to  both  missions  are  identified  and  understood  prior  to  the  decision  to 
implement  a  change.  Otherwise,  the  resolution  of  one  issue  may  result  in  an  even  greater  problem.  Sometimes,  a  mutually  beneficial  decision 
is  not  possible,  in  which  case  a  compromise  decision  may  be  in  order.  The  worst  decision  would  be  one  that  resolves  one  issue  without  any 
regard  to  impact  on  the  other  mission. 

The  Payload  should  be  included  in  change  control  activities  for  modifications  that  have  potential  to  affect  their  mission. 

Table  12.  Configuration  Management  Checklist 


Item 

Topic 

Consideration 

Comments 

CM1 

Technical 

requirements 

Configuration  management  requirements  must  be 
defined  and  communicate  changes  as  they  occur  in  the 
technical  and  programmatic  requirements  on  either  the 
host  or  payload  if  they  impact  the  other.  A  change 
control  process  needs  to  be  in  place. 

Included  are  documentation  of  agreements  and 
revisions  to  environmental,  operational  electrical, 
mechanical,  software,  and  algorithms  that  impact 
host/payload  relationship.  This  shall  include 
design  phase  as  well  as  post  payload  to  host 
delivery. 

CM2 

Unresolved  issues 

Tracking  and  resolve  design  issues  (TBDs). 

Resolving  issues  such  as  what  the  outer  material 
on  layers  of  multi-layer  insulation  should  be 
completed  early  enough  to  permit  incorporation  of 
that  change  into  the  design  of  the  host  or  payload. 

CM3 

Test  plans  and 
results 

Documentation,  planning,  and  the  results  from 
mechanical,  electrical,  and  RF  pathfinders  and  from 
tests  that  impact  host/payload  relationships  must  be 
distributed  and  controlled. 

Control  needed  to  eliminate  surprises  and 
demonstrate  performance. 

CM4 

Interface 

Interface  documentation  of  mechanical,  electrical, 
software,  firmware,  and  communications  commonalities 
must  be  controlled. 

It  is  important  to  keep  track  of  host/payload 
changes  that  would  impact  the  other.  Post 
payload  delivery  decisions  that  impact  interfaces 
should  include  payload  representative  for 
approval. 
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Item 

Topic 

Consideration 

Comments 

CM5 

Thermal 

Modifications  to  the  thermal  design  requirements  and 
test  results  of  either  the  host  or  payload  must  be 
documented  in  a  controlled  manner. 

Thermal  design  of  either  the  host  or  payload  may 
require  (or  benefit  from)  modifications  of  either  the 
host  or  payload  depending  on  the  selection  of 
materials  and  usage.  Thermal  design  includes 
interface  power,  thermal  control  services,  and 
common  nodes  as  well  as  spacecraft  orientation, 
ConOps,  and  understanding  the  effect  of  external 
structures  such  as  antennas,  thermal  blankets, 
and  solar  arrays. 

CM6 

Mechanical  and 
Structural 

Mechanical  and  structural  documentation,  planning,  and 
test  results  that  impact  host/payload  relationships  must 
be  distributed  and  controlled.  Representative  mass 
mock-up  of  the  payload  should  be  provided  for  host 
testing  of  mass  properties,  vibration,  and  shock. 

A  physical  confirmation  well  in  advance  of  the 
installation  of  the  payload  should  take  place  to 
confirm  the  interface.  If  the  payload  is  not 
available,  a  mass  mock-up  that  represents  the 
weight  and  eg  of  the  payload  should  be  provided 
for  testing,  or  to  replace  the  Payload  if  it  is  late. 

CM7 

Mechanical  and 
Electrical  Design 
Documentation 

Allow  host  and  payload  viewing  of  design  of  components 
identified  in  the  interface  control  documentation  payload 
design.  A  change  control  process  needs  to  be  in  place. 

Ensure  design  software  used  is  compatible. 

Viewer  programs  exist  for  nearly  all  design 
applications. 

CM8 

ConOps 

Definition  of  the  Concept  of  Operations  that  impact 
host/payload  relationships  must  be  distributed  and 
controlled. 

The  impact  on  a  payload,  for  example,  if  it  is 
required  to  operate  in  full  sunlight  could  be  very 
important  if  it  were  designed  to  operate  only  in  the 
shadow. 

CM9 

Control  of  Design 

Involve  the  Host  and  the  Payload  in  “use-as-is,”  “rework 
to  specifications,”  decisions  that  impact  the  other  or  the 
interfaces. 

Avoid  potential  failures  due  to  lack  of 
understanding  of  impact  on  the  Payload. 

CM10 

Prohibited  Materials 

A  prohibited  materials  list  must  be  maintained. 

This  would  provide  a  clear  impact  of  materials 
utilized  to  the  other  party. 

CM1 1 

Control  of  Support 
Materials 

An  approved  support  materials  list  should  be  maintained. 

This  would  provide  a  checklist  of  materials  that 
can  be  used  in  vacuum  with  flight  equipment. 

CM12 

Test  Results 

Capture,  explain,  and  document  testing  on  the  unit  under 
test  that  impact  host/payload  relationships  must  be 
distributed  and  controlled. 

Sets  expectation  for  integration  testing. 

CM13 

Test  Procedures 

Provide  intended  test  procedures  and  conditions  that 
impact  host/payload  relationships  must  be  distributed 
and  controlled. 

This  includes  such  aspects  as  ramp  rates, 
temperature  cycles,  power  levels,  data  acquisition 
rate  to  ensure  that  conditions  planned  by  the  host 
will  be  acceptable  to  the  payload  design. 

CM14 

Assembly 

The  host  shall  coordinate  the  control  of  mating 
procedures  and  cable  routing. 

Ensure  alignment  of  needs. 
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Item 

Topic 

Consideration 

Comments 

CM15 

Control  of  Analysis 
Tools 

Input  parameters,  assumptions,  starting/boundary 
conditions  must  be  consistent  between  Host  and 

Payload  if  analysis  roles  are  shared  (thermal,  structural, 
RF,  etc). 

Reduces  chance  of  misleading  results  or  incorrect 
conclusion  that  a  “gap”  may  exist  or  not. 

CM16 

Access  to 

Information 

The  Payload  provider  should  ensure  Contractor  access 
to  interfacial  design  information  in  a  timely  manner. 

The  Payload  provider  may  obtain  parts,  units,  or 
processes  from  outside  vendors  or  US 
government  sources.  This  may  inhibit  the  Payload 
provider  from  sharing  key  interface  information 
with  the  Host/Contractor  in  a  timely  manner, 
hindering  the  design  process. 

CM17 

Parts  and  Materials 
Lists 

Parts  and  Materials  lists  are  standard  for  the  Host. 

Similar  lists  should  be  provided  by  the  Payload  for  host 
review. 

Part  requirements  for  the  Payload  may  be 
different  from  the  Host,  but  all  should  be  robust 
against  the  space  environment. 

Contamination 

When  either  a  Host  or  Payload  has  contamination  sensitive  equipment  such  as  optics;  detectors;  highly  sensitive  thermal  surfaces;  or 
equipment  that  is  to  be  operated  at  significantly  colder  temperatures  than  adjacent  areas  and  equipment,  contamination  requirements  should  be 
defined.  Because  of  differing  requirements  and  manufacturing  flows,  it’s  necessary  for  the  payload  and  host  to  jointly  negotiate  a  detailed 
contamination  control  plan  that  ensures  sufficient  cleanliness  during  manufacturing,  test,  shipment,  and  launch,  as  well  as  on  orbit. 

On-orbit  contamination  measures  such  as  foreign  object  debris  (FOD)  restrictions  or  venting  pathway  design  may  also  be  required.  It  is 
anticipated  that  both  the  host  and  the  hosted  payload  will  incorporate  some  measure  of  protection  from  contamination,  particularly  if  there  is  a 
sensitive  payload  involved. 

A  particular  area  of  concern  is  the  use  of  commercial-off-the-shelf  (COTS)  equipment.  Since  COTS  equipment  manufacturers  do  not  normally 
consider  space  environments  in  the  design  of  their  equipment,  verification  of  compatibility  by  test  and/or  preventive  measures  are  required. 
Monitored  bakeout  is  an  example  of  test  and  preventive  measures. 

Table  13.  Contamination  Checklist 


Item 

Topic 

Consideration 

Comments 

CC1 

Purge  Requirements 

Purge  requirements  must  be  defined  early  to  design  gas 
transmission  for  shipment,  integration,  dynamics,  TA/,  EMI,  and 
at  launch  base. 

Purge  requirements  should  be 
avoided  if  they  are  not  critical  for 
performance  of  the  Host  or  Payload. 

CC2 

Purge  Rates 

Purge  rates  should  be  compared  to  available  gas  supply  for 
shipments  to  ensure  sufficient  supply  for  contingencies. 
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Item 

Topic 

Consideration 

Comments 

CC3 

Purge  Gas  Safety 

Purge  gasses  are  likely  not  gasses  that  support  life.  Areas  where 
purge  is  to  take  place  should  be  surveyed  to  ensure  no  gas 
buildup  is  possible. 

CC4 

Bagging 

Bagging  is  likely  needed  to  protect  sensitive  surfaces  in  a  normal 
high-bay  environment. 

Bagging,  also,  should  be  avoided 
unless  necessary  for  thermal  or 
optical  performance. 

CC5 

Bagging  and  Dynamics  Testing 

Bagging  should  be  designed  to  not  interfere  with  any  acoustic  or 
vibration  testing. 

CC6 

Bagging  and  EMI  and  RF 

Testing. 

It  might  be  advisable  to  use  RF  transparent  bagging  so  that 
sensitive  surfaces  need  not  be  exposed  during  EMC  and  other 

RF  testing. 

CC7 

Cryogenic  Temperatures 

Ground  operations  that  are  required  at  cryogenic  temperatures 
should  be  planned  in  advance  to  ensure  appropriate 
environments. 

CC8 

Thermal  Vacuum  Testing 

It  is  unlikely  that  bagging  will  be  effective  during  pump  down. 
Purging  during  pump  down  is  also  difficult. 

Special  planning  may  be  required  to 
maintain  cleanliness  during  TA/ 
testing. 

CC9 

Thermal  Vacuum  Testing 

Sensitive  surfaces  should  be  kept  warmer  than  the  surroundings 
during  repressurization  if  possible  to  avoid  condensation  of 
plasticizers  and  other  contamination. 

CC10 

Launch  Base 

Launch  base  cleanliness  varies  from  site  to  site. 

Geosynchronous  launch  facilities  may  be  class  100,000  as  may 
fairings. 

Plans  to  maintain  cleanliness  at 
launch  base  should  be  made  well  in 
advance.  Purge  carts  and  filters  must 
be  manifested  months  in  advance  of 
launch. 

CC11 

Launch 

Sensitive  surfaces  should  be  maintained  warmer  than  their 
surroundings,  or  should  be  covered  with  deployable  covers, 
during  ascent  to  avoid  condensation  of  contaminants. 

CC12 

Post-launch 

Cryogenic  surfaces  can  condense  materials  even  in  the  near¬ 
vacuum  of  space. 

Consideration  should  be  given  to  allowing  time  for  the  host  or 
payload  to  outgas  before  going  cryo  or  opening  deployable 
covers  for  optics  or  radiators. 

Primary  payload  could  be  tested  in 
orbit  while  spacecraft  and  payload 
outgas  and  dry. 

CC13 

Bakeout 

Consideration  should  be  given  to  baking  out  surfaces  (e.g., 
blankets)  near  a  sensitive  payload. 

CC14 

Thruster  Plumes 

Plumes  for  liquid  propellant  thrusters  should  be  modeled  to 
ensure  their  impingement  and  collection  rates  on  sensitive 
surfaces  are  acceptable. 
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Item 

Topic 

Consideration 

Comments 

CC15 

Sputtering  Products 

Sputtering  products  resulting  from  electric  propulsion  use  should 
be  modeled  to  ensure  their  impingement  and  collection  rates  on 
sensitive  surfaces  are  acceptable. 

CC16 

COTS 

COTS  products  are  not  designed  for  low  outgassing  rates  and 
should  be  thoroughly  investigated  and  tested  to  ensure  they  will 
not  affect  sensitive  surfaces. 

CC17 

Vacuum  Compatibility 

Needless  to  say,  all  materials  used  within  a  vacuum  chamber 
with  a  sensitive  payload  should  be  controlled  and  vacuum 
compatible. 

Zinc,  Cadmium,  Mercury  and  other 
metals  can  sublime  in  vacuum  and 
redeposit  on  cold  surfaces.  Many 
organics  can  also  contaminate. 

CC18 

Cleaning 

Cleaning  procedures  after  delivery  should  be  specified,  as 
should  any  support  equipment  and  environmental  requirements. 

CC19 

Cleanliness  Requirements 

Cleanliness  requirements  can  influence  effort.  For  the  most 
economical  mission,  expensive  operations  such  as  purge  in  the 
fairing  should  be  avoided. 

CC20 

Venting  Analysis 

A  venting  analysis  should  be  performed  to  determine  the  flow 
path  and  flow  rates  that  will  occur  during  decompression  to  a 
vacuum.  These  vent  paths  need  to  be  steered  away  from 
sensitive  surfaces. 

CC21 

Venting  Paths 

Venting  paths  should  be  checked  to  ensure  they  do  not  vent  into 
contamination  sensitive  areas. 

CC22 

Thruster  Locations 

Thruster  locations  should  be  checked  to  ensure  their  plumes  will 
not  affect  contamination  sensitive  areas. 

CC23 

FOD 

Ensure  apertures  and  openings  are  protected  to  the  extent 
possible.  Implement  FOD  control  procedures. 
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Electrical  Interface  Design  and  Integration 


The  proper  operation  of  electrical  interfaces  between  the  Host  and  the  Payload  is  fundamental  to  the  success  of  the  combined  missions. 
Electrical  interfaces  are  susceptible  to  subtle  effects  that  are  sometimes  difficult  to  analyze.  Additionally,  integration  of  the  Payload  with  the 
Host  may  occur  late  in  the  Host’s  integration  flow.  This  potential  for  late  discovery  of  electrical  interface  design  issues  represents  a  significant 
risk  to  the  Host. 

This  risk  can  be  mitigated  by  implementing  a  sound  electrical  interface  design  and  validation  approach.  Robust  and  comprehensive  interface 
requirement  definitions  that  incoiporate  appropriate  performance  margins  can  significantly  reduce  the  risk  of  non-functioning  interfaces. 
Further  risk  mitigation  is  encouraged  thru  the  execution  of  interface  validation  testing  not  only  as  part  of  unit  acceptance  test  but  also  with 
early  end-to-end  demonstrations  using  engineering  models  and  flight  like  harness  assemblies.  Lastly,  forethought  is  required  to  ensure  that 
damage  is  avoided  during  Host-Payload  integration  by  implementing  appropriate  connector  inspection  and  mating  criteria. 

Table  14.  Electrical  Interface  Design  and  Integration  Checklist 


Item 

Topic 

Consideration 

Comments 

Ell 

Configuration 

Management 

Documentation  defining  the  electrical  interfaces  must  be 
controlled  and/or  approved  by  the  Host.  Typically, 
documentation  of  interfaces  is  captured  in  an  Interface 
Requirements  Document  (IRD),  Interface  Control  Document 
(or  Drawing)  (ICD),  and  in  Schematics. 

The  Host  is  ultimately  responsible  for  ensuring  that 
the  electrical  interfaces  will  not  induce  harm  to  the 
primary  mission.  Uncoordinated  interface  design 
changes  by  the  Payload  must  be  prevented. 

Similarly,  arbitrary  changes  by  the  Host  could 
degrade  the  Payload’s  performance. 

EI2 

Requirements 

Develop  comprehensive  requirements  for  each  interface  type 
needed  to  support  the  payload  (power,  digital  data,  RF 
modulated  data,  command  and  telemetry  signals,  pin 
programming,  etc.). 

Definition  of  voltage  levels,  timing  characteristics, 
and  modulation  methods  are  key  items.  Additionally, 
definition  of  data  and  message  protocols  should  be 
included  to  ensure  compatibility. 

EI3 

Requirements 

Signal  characteristics  should  be  defined  at  the  connector 
interface  between  the  host  and  the  payload. 

This  will  prevent  potential  gaps  in  interface  analyses 
in  cases  where  the  Payload  provides  a  portion  of  the 
interfacing  harnesses. 

EI4 

Analysis 

Perform  Worst  Case  Circuit  Analyses  on  the  electrical 
interfaces  to  ensure  that  all  interface  types  will  remain  within 
specification  throughout  mission  life. 

Refer  to  section  4.4.5  and  4.4.6  for  a  detailed 
description  of  Interface  Worst  Case  and  Timing 
analyses. 

EI5 

Analysis 

Harness  voltage  drop  and  signal  attenuation  effects  must  be 
considered  to  ensure  proper  operation  of  the  Payload. 

This  is  necessary  to  ensure  that  an  adequate  DC 
voltage  level  is  provided  to  the  Payload  units  and 
that  the  telemetry  and  command  signal  work 
properly. 
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Item 

Topic 

Consideration 

Comments 

EI6 

Analysis 

Perform  reliability  and  failure  mode  analyses  to  ensure  that 
the  failure  modes  of  the  interface  and  their  probability  are  well 
understood.  This  must  include  evaluation  of  potential  single 
point  failures  and  propagating  failures.  Permanent  effects  from 
Single  Event  Effects  (SEE)  analysis  such  as  Latchup  should 
also  be  included  in  the  failure  mode  analysis. 

This  analysis  provides  important  data  for 
development  of  Fault  Protection  features  in  the  Host 
and  the  Payload.  See  the  Safety  and  Reliability 
Checklist  for  more  details. 

EI7 

Harness/Cable  Lengths 

Care  must  be  taken  when  determining  the  cable  lengths 
between  Host  and  Payload.  Long,  circuitous  routes  may  be 
needed  to  host  a  payload. 

Detrimental  effects  such  as  voltage  drop,  signal 
attenuation  and  cross-talk  all  vary  with  cable  length. 

EI8 

Return  Paths 

Signal  and  Power  return  paths  should  be  matched  between 
the  Host  and  the  Payload. 

See  the  Power  Checklist  for  additional 
considerations  for  power  and  ground  interface 
considerations. 

EI9 

Mis-mates 

Prevent  mating  the  wrong  connectors  together  by  utilizing 
variations  in  connector  type,  keying  features,  and  color 
coding.  Use  unique  connector  ID  markings  as  much  as 
possible  on  the  units  and  harnesses. 

Units  made  up  of  multiple  identical  slices  are  the 
most  likely  to  experience  mis-mates. 

EI10 

Shielding 

Determine  whether  interfaces  are  susceptible  to  cross-talk 
interference  from  other  lines  in  the  harness  bundle  and  define 
appropriate  wire  type,  shielding  or  separation  requirements. 

Ell  1 

External  Harnesses 

Harness  bundles  that  are  external  to  the  Host  vehicle’s 

Faraday  cage  will  need  additional  shielding  to  mitigate  ESD 
susceptibility,  radiation  damage,  and  micrometeoroid  damage. 

El  1 2 

Validation  and  Test 

Interface  risk  can  be  reduced  with  early  validation  of  interfaces 
using  engineering  models  or  interface  simulators  to  perform 
compatibility  tests.  Duplicate  flight  harness  types  and  lengths 
to  ensure  representative  results. 

Early  demonstration  of  interface  compatibility  should 
be  performed  whenever  possible  to  reduce  risk  of 
integration  delays  late  in  the  program. 

El  1 3 

Inspection 

Introduction  of  new  connector  types  may  require  updates  to 
the  Host’s  existing  generic  inspection  criteria  for  connector 
mates  and  demates. 

El  1 4 

Assembly  Planning 

Introduction  of  new  connector  types  may  require  special 
planning  instructions  for  proper  execution  of  connector  mates 
and  demates. 

Special  tooling,  torque  requirements  and  fastener 
definitions  for  new  connector  types  must  clearly 
defined  for  the  integration  technicians. 
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EMI/EMC 


The  performance  of  the  Payload  and  of  the  Host  can  potentially  be  degraded  by  either  radiated  electromagnetic  interference  (RF)  or  conducted 
electromagnetic  interference  (line  noise,  ripple,  etc.)  between  the  two  entities.  It  is  critical  that  detailed  requirements  be  established  between 
the  two  entities  to  ensure  that  electromagnetic  compatibility  is  achieved.  Specifically,  that  both  the  Host  and  the  Payload  will  be  safe  and  will 
operate  properly  for  all  operating  modes  and  mission  phases. 

Table  15.  EMI/EMC  Checklist 


Item 

Topic 

Consideration 

Comments 

EMI 

Radiated  Emissions 

Establish  interface  requirements  for  the  minimum  allowable 
radiated  electromagnetic  emissions  safety  margins  between 
the  Host,  the  Payload  and  the  launch  vehicle. 

Note  that  the  margin  required  may  vary 
between  these  three  entities. 

EM2 

Radiated  Emissions 

Define  the  radiated  emissions  environment  generated  by  the 
Host. 

EM3 

Radiated  Emissions 

Define  the  radiated  emissions  environment  generated  by  the 
Payload. 

EM4 

Radiated  Emissions 

Define  the  radiated  emissions  environment  generated  by  the 
launch  vehicle  and  by  other  systems  at  the  launch  site. 

EM5 

Radiated  Susceptibility 

Define  the  radiated  emissions  limits  that  are  imposed  by  the 
Host. 

EM6 

Radiated  Susceptibility 

Define  the  radiated  emissions  limits  that  are  imposed  by 
Payload. 

EM7 

Radiated  Susceptibility 

Define  the  radiated  emissions  limits  that  are  imposed  by  the 
launch  vehicle  and  its  systems. 

EM8 

Radiated  Susceptibility 

Identify  all  frequency  ranges  for  which  the  minimum  radiated 
emission  safety  margin  is  not  satisfied  for  the  Host,  the 

Payload  and  for  the  launch  vehicle.  Examine  potential  design 
changes  and/or  more  extensive  EMI/EMC  testing  that  will 
improve  and  demonstrate  safety  margins  and  compatibility  for 
these  frequency  ranges. 

EM9 

Conducted  Emissions 

Establish  interface  requirements  for  the  minimum  allowable 
conducted  electromagnetic  emissions  safety  margins  between 
the  Host,  the  Payload  and  the  launch  vehicle. 

Note  that  the  margin  required  may  vary 
between  these  three  entities. 

Conducted  emissions  are  transmitted 
through  the  direct  electrical  interfaces 
between  entities. 

EM10 

Conducted  Emissions 

Define  the  conducted  emissions  environment  generated  by 
the  Host. 

EM1 1 

Conducted  Emissions 

Define  the  conducted  emissions  environment  generated  by 
the  Payload. 
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Item 

Topic 

Consideration 

Comments 

EM12 

Conducted  Emissions 

Define  the  conducted  emissions  environment  generated  by 
the  launch  vehicle. 

EM13 

Conducted 

Susceptibility 

Define  the  conducted  emissions  limits  that  are  imposed  by  the 
Host. 

EM14 

Conducted 

Susceptibility 

Define  the  conducted  emissions  limits  that  are  imposed  by 
Payload. 

EM15 

Conducted 

Susceptibility 

Define  the  conducted  emissions  limits  that  are  imposed  by  the 
launch  vehicle  and  its  systems. 

EM16 

Conducted 

Susceptibility 

Identify  all  frequency  ranges  for  which  the  minimum  conducted 
emission  safety  margin  is  not  satisfied  for  the  Host,  the 

Payload  and  for  the  launch  vehicle.  Examine  potential  design 
changes  and/or  more  extensive  EMI/EMC  testing  that  will 
improve  and  demonstrate  safety  margins  and  compatibility  for 
these  frequency  ranges. 

EM17 

DC  Magnetics 

Define  the  DC  magnetic  flux  and  dipole  environment 
generated  by  the  Host  for  the  locations  of  the  Payload’s 
hardware. 

EM18 

DC  Magnetics 

Define  the  DC  magnetic  flux  environment  generated  by  the 
Payload’s  hardware. 

EM19 

DC  Magnetics 

Define  the  DC  magnetic  flux  limitations  that  are  imposed  by 
the  Host. 

EM20 

DC  Magnetics 

Define  the  DC  magnetic  flux  limitations  that  are  imposed  by 
the  Payload. 

EM21 

DC  Magnetics 

Confirm  that  sufficient  margin  exists  between  the  Host  and 
Payload  for  DC  magnetic  environments. 

EM22 

Test 

The  Host  and  Payload  should  be  tested  in  stowed  and 
deployed  conditions  (as  applicable)  for  all  radiated  emissions. 

Lack  of  this  type  of  testing  has  resulted 
in  degraded  performance  on  orbit. 

EM23 

PIM 

Surfaces  of  Host  and  Payload  should  be  examined  to  ensure 
that  neither  will  introduce  PIMs  in  the  other’s  transmissions. 

Preventive  measures  such  as  PIM 
blankets  should  be  designed  and 
provided  space  and  clearance  early  in 
the  project. 
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Fault  Management 


Fault  Management  is  a  coordinated  effort,  combining  a  fault  tree  with  potential  fault  symptoms  detected  by  state  of  health  (SOF1)  telemetry 
(TLM)  and  transmitted  to  the  ground  station.  The  Failure  Modes  and  Effects  Analysis  (FMEA)  can  be  used  to  identify  the  candidate  failure 
causes  by  working  in  reverse  order  to  the  unit  or  assembly  level.  Autonomous  FSW  is  developed  to  correct  and  mitigate  Flost  and  Payload 
failure  effects  that  are  time-critical.  Examples  could  be  failure  effects  with  short  thermal  time  constants  or  when  the  Flost  is  not  visible  to  the 
ground  station.  When  commanding  the  Flost  and  Payload  manually  during  specific  mission  phases,  avoid  commands  on  the  prohibited  list. 

Table  16.  Fault  Management  Checklist 


Item 

Topic 

Consideration 

Comments 

FM1 

Time  Critical  Failures 

Verify  that  potential  propagating  failure  modes  needing  timely 
correction  to  a  Host  “safe  mode”  have  autonomous  detection 
and  mitigation. 

The  Host  may  have  limited  onboard 
SOH  data  available  from  the  Payload, 
so  Host  action  must  be  robust. 

FM2 

Not  in  LOS  of  Ground 
Station 

Verify  that  potential  propagating  failure  modes  needing  timely 
correction  to  a  “safe  mode”  have  autonomous  detection  and 
mitigation. 

FM3 

Maintain  High 
Performance 

Availability 

Payloads  requiring  high  performance  availability  may  require 
autonomous  detection  and  mitigation  of  failures. 

FM4 

Ground  Over-ride 
Capability 

In  the  event  of  Payload  processor  failures,  ground  over-ride 
capability  is  needed. 

FM5 

Selecting  the  Failure 
Detection  Monitor 

Based  upon  a  combination  of  analysis  and  tests,  select  the 
failure  monitor  (e.g.,  current,  voltage,  temperature,  watch-dog 
timer,  etc.)  that  results  in  the  most  accurate  and  timely  failure 
detection. 

Payloads  with  multiple  failure  modes 
may  require  multiple  monitors  on 
Payload  or  Host  side. 

FM6 

Encryption 

Strategies  should  be  developed  to  accommodate  fault 
management  for  encrypted  Host  command  links  and  any 
encrypted  Payload  commands. 

FM7 

Fault  Management 
Architecture 

Payload  faults  that  have  criticality  to  Host  may  need  mitigation 
on  both  Payload  and  Host  sides  of  interface.  Host  faults  that 
affect  Payload  should  be  understood  and  mutually  mitigated. 

Ownership  of  monitoring  at  Payload 
and  Host  levels  must  be  understood 
at  System  level  to  avoid  gaps. 

A- 15 


Materials,  Processes  and  Parts 


Parts  and  materials  used  in  the  Host  or  Payload  should  be  prevented  from  jeopardizing  the  other’s  mission.  This  is  normally  controlled 
through  review  of  approved  parts  and  material  lists  that  provide  essential  characteristics  for  evaluation.  If  a  sufficient  parts  or  materials  list  is 
not  available  due  to  the  use  of  COTS  items,  testing  may  be  required  to  verify  no  harmful  products  evolve  from  the  planned  use. 

Useful  reference  documents  for  this  section  include  TOR-2006(8583)-5236  Rev  B  and  EEE-INST-002.  The  SAE  Q100  through  Q200  series  of 
automotive  grade  parts  may  be  useful  reference  for  lower  class  missions. 

Table  17.  Materials  and  Processes  Checklist 


Item 

Topic 

Consideration 

Comments 

MP1 

Materials 

The  Payload  or  the  Host  should  not  use 
materials  on  a  Prohibited  Materials  List  without 
mutual  approval. 

Such  materials  include  some  metal  that  sublime  and  redeposit; 
platings  that  can  grow  whiskers  and  organic  materials  that  outgas. 

MP2 

FOD 

Foreign  debris  should  be  avoided. 

FOD  control  programs  at  the  unit  level  and  system  level  should  be 
implemented  to  decrease  the  chance  of  debris  causing  problems 
in  test  and  on  orbit. 

A  line  of  sight  analysis  could  be  performed  if  FOD  were 
considered  a  risk  for  the  Host  or  Payload  mission. 

MP3 

Processes 

Develop  a  spacecraft  integration  flow  chart  and 
procedures  defining  all  assembly  steps, 
responsibilities  and  configurations. 

Specify  how  the  payload  will  be  stored  upon  arrival,  uncrated, 
installed,  and  tested.  The  procedure  should  detail  the  equipment, 
steps  and  resource  involvement.  Typical  concerns  are  the  need  for 
possible  nitrogen  purges  and  the  need  to  uncrate  in  clean  rooms. 
End  to  end  responsibilities  and  conflict  resolution  need  to  be 
defined. 

MP4 

Processes 

Develop  a  test  flow  chart  and  procedure  defining 
all  steps  in  testing  under  the  control  of  the  host. 

Specify  what  is  to  be  measured  and  the  equipment  to  be  used  by 
detailing  the  steps  and  resource  involvement. 

Instances  where  the  payload  was  tested  in  vacuum  chambers  that 
had  just  been  refurbished  and  then  outgassed,  where  incorrect 
temperature  limits  or  power  levels  were  applied  during  thermal 
tests  or  where  power  was  applied  to  a  data  line  must  be  avoided. 

MP5 

Processes 

Payload  integration  and  testing  shall  include  a 
representative  from  the  payload  provider. 

The  responsibility  of  the  representative  is  to  guide  the  integrator 
through  the  intricacies  of  the  payload  and  to  insure  no  harm  is 
done  to  the  payload. 

MP6 

Processes 

In-flight  processes  must  take  account  of  the  host 
or  payload  vulnerabilities. 

In-flight  processes  such  as  deployment  of  a  payload,  experiments 
within  the  host  or  payload  or  operation  of  solar  arrays  shall  not 
adversely  affect  the  other. 

MP7 

Processes 

Manufacturing  processes  should  follow  proven 
flight  standards. 

The  NASA  8739  series  is  typical  for  traditional  manufacturing 
workmanship  requirements. 

MP8 

Processes 

Any  new  processes  should  be  fully  qualified  and 
documented. 

Qualification  should  be  at  the  process  level,  and  at  the  unit  level. 
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Item 

Topic 

Consideration 

Comments 

MP9 

PMP  Review 

Board 

A  review  board  should  be  established  for  review 
and  approval  of  all  parts  and  materials. 

The  review  board  serves  to  identify  issues  early  in  the  process 
before  final  parts  and  material  lists  are  delivered.  All  participants 
should  have  a  representative  on  the  board. 

MP10 

Parts  and 

Materials  Lists 

Parts  and  Materials  lists  are  standard  for  the 

Host.  Similar  lists  should  be  provided  by  the 
Payload  for  host  review. 

Part  requirements  for  the  Payload  may  be  different  from  the  Host, 
but  all  should  be  robust  against  the  space  environment. 

Mechanical  Integration  and  Test 

Integration  and  test  of  any  satellite  can  occasionally  present  issues  that  were  not  evident  during  the  design  phase.  There  are  a  few  specific 
considerations  that  should  be  addressed  with  regard  to  hosted  payloads  to  ensure  that  both  Host  and  Payload  are  safely  integrated  and  tested. 
For  example,  it  may  be  important  to  consider  de- integration  of  a  hosted  payload.  De-integration  and  other  considerations  are  listed  in  the 
checklist  below. 

Table  18.  Mechanical  Integration  and  Test  Checklist 


Item 

Topic 

Consideration 

Comments 

Mil 

Test  Orientation 

Physical  orientation  of  hosted  payload  during  testing 
operations  may  require  more  analysis;  1G  loading  may  also 
affect  alignments.  Will  offloading  be  required? 

May  only  be  an  issue  if  hosted  payload 
was  not  designed  for  space.  Can 
hosted  payload  be  “tipped”  or  mounted 
on  its  side  if  necessary  for  testing? 

MI2 

Environmental  Testing 

Test  notching,  if  permitted  by  LV  provider,  may  be  required 
solely  because  of  the  addition  of  the  hosted  payload. 

MI3 

Grounding 

Ensure  that  grounding  of  all  individual  components  of  hosted 
payload  is  adequate;  one  ground  path  between  a  hosted 
payload  subassembly  and  the  host  is  not  sufficient. 

All  components  need  to  be  grounded 
individually,  not  grounded  as  one 
subassembly.  May  need  additional 
ground  beads,  studs,  copper  tape,  or 
straps. 

MI4 

Integration  Accessibility 

Consider  mounting  methods  and  accessibility  for  integration. 

Externally  mounted  components  (with 
reference  to  the  host)  may  be  easier  to 
install. 

MI5 

De-Integration 

Consider  accessibility  and  removal  methods  and  accessibility 
for  hosted  payload  components. 

Externally  mounted  components  (with 
reference  to  the  host)  may  be  easier  to 
remove  if  necessary. 

MI6 

Configuration 

Management 

Keeping  separate  drawings  and  bills  of  materials  for  hosted 
components  may  assist  in  efficiency  of  integration. 

Especially  good  if  deintegration 
required. 

MI7 

Fit  Checks 

Hole  Patterns,  Flatness. 

Common  drill  templates  and  early  fit 
checks  are  necessary  to  reduce  risk. 

MI8 

Axes  Definitions 

Definition  of  axes  should  be  agreed  upon  during  the  design 
phase,  but  would  be  verified  during  alignments. 
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Optics 

Visible  optics,  optical  communications  devices,  infrared,  radar  and  other  line-of-sight  sensors  are  often  contamination  sensitive  and  require 
careful  contamination  control  which  is  addressed  in  the  previous  checklist.  They  may  have  stability  requirements  as  addressed  in  the  ACS 
checklist  and  thermal  distortion  considerations  that  are  related  to  thermal  design. 

Since  optical  payloads  will  be  one  of  the  most  common  types  of  hosted  payloads,  and  since  they  do  have  additional  considerations,  they  are 
included  as  a  separate  checklist. 

Table  19.  Optics  Checklist 


Item 

Topic 

Consideration 

Comments 

OP1 

Field  of  View 

Most  sensors  and  optical  equipment  require  an  unobstructed  field  of  view. 
This  can  be  ensured  using  computer  models  such  as  Pro-E,  but  it  is 
important  to  fully  understand  the  geometry  and  origin  of  defined  stay-out 
zones,  including  potentially  unmodeled  integration  hardware  such  as 
blankets  and  fasteners. 

OP2 

Field  of  View 

Many  sensors  have  susceptibility  to  glints,  reflections  or  thermal  radiation 
originating  from  regions  outside  their  field  of  view.  Again,  these 
requirements  must  be  fully  understood  and  verified  by  computer  models. 

OP3 

Contamination 

Aspects  of  contamination  addressed  in  the  Contamination  checklist  should 
be  examined  to  determine  whether  they  apply  to  the  instrument  in 
question.  Optics  line  of  sight  to  known  contamination  sources  should  be 
avoided. 

OP4 

Pointing 

Are  thermal  expansion  coefficients  between  Host  and  Payload  sufficiently 
similar  that  pointing  errors  are  not  introduced? 

OP5 

Pointing 

Will  thermal  distortions  on  Host  surfaces  cause  the  Payload  to  off-point 
excessively? 

OP8 

LOS  Knowledge 

Optical  payloads  often  require  more  accurate  line-of-sight  knowledge 
(LOSK)  than  other  missions  such  as  a  communications  satellite.  The 
impact  of  adding  a  hosted  optical  payload  to  the  spacecraft  could  be 
lessened  if  the  host  is  amenable  to  modifying  the  LOSK  sensor  to  satisfy 
hosted  payload  requirements. 

OP9 

Pointing 

Jitter  requirements  and  performance  should  be  analyzed  to  ensure  the 
mission  will  perform  as  intended. 

OPIO 

Pointing 

Optical  axes  and  boresights,  as  well  as  the  plan  to  ensure  their  alignment 
should  be  addressed  early  in  the  program. 
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Power 


Power  may  be  supplied  from  the  spacecraft  bus,  or  may  be  downconverted  in  voltage  and  supplied  on  a  dedicated  line  to  the  Payload.  Since 
the  payload  will  rely  on  the  host  as  a  DC  power  source,  it  is  critical  that  detailed  power  interface  requirements  be  established  between  the  two 
entities.  The  purpose  of  these  requirements  is  to  ensure  the  safety  and  proper  operation  of  both  the  host  and  the  payload  in  all  operating  modes 
and  mission  phases.  Good  references  for  power  systems  include  MIL-STD-1541  for  EMC  and  SAE  AS5698  for  power  systems  in  general. 

Table  20.  Power  Checklist 


Item 

Topic 

Consideration 

Comments 

PW1 

Fusing 

Assign  whether  the  host  or  the  payload  will  provide  fusing 
protection  on  the  payload’s  power  inputs. 

PW2 

Fusing 

Determine  the  fuse  size  requirements  to  ensure  reliable  and 
quick  response  to  short  circuit  conditions  in  the  payload. 

PW3 

Circuit  Breakers 

Determine  the  circuit  breaker  dynamic  performance  to  ensure 
reliable  and  quick  response  to  short  circuit  conditions  in  the 
payload. 

Over  current  control  within  the  payload  must 
be  compatible  with  the  circuit  breaker 
behavior. 

PW4 

Nominal  Power 
Consumption 

Determine  the  nominal  and  worst  case  power  consumption 
requirements  for  all  of  the  payload’s  operating  modes  and  for  all 
of  the  host’s  mission  phases. 

Uncertainty  in  power  consumption  early  in 
Payload  development  phases  should  be 
managed  by  power  budgets  and  margin 

Power  feeds  and  cables  should  be 
appropriately  sized. 

PW5 

Abnormal  Power 
Consumption 

Identify  any  potential  payload  failure  modes  that  would  result  in 
abnormally  high  power  consumption  that  is  insufficient  to  blow 
the  fuses. 

The  fuses  should  be  sized  such  that  any 
such  shorts  are  tolerable  to  the  Host.  If  not, 
the  Host  should  be  capable  of  manually  or 
autonomously  shutting  down  the  Payload. 

PW6 

Leakage 

Determine  “Off”  state  power  consumption  limits  for  the  payload 
consistent  with  all  host  mission  phases. 

The  Host  may  consider  implementing  an 
isolation-capable  power  bus  for  the 

Payload. 

PW7 

In-rush  Current 

Determine  in-rush  current  limits  for  the  payload  to  apply  to 
payload  power  up  and  step  load  changes  for  its  operating 
modes. 

Current  limits  should  be  determined  by 
fuse/circuit  breaker  characteristics. 

PW8 

Out-rush  Current 

Determine  out-rush  current  limits  for  the  payload  to  apply  to 
payload  power  down  and  step  load  changes  for  its  operating 
modes. 

Current  limits  should  be  determined  by 
fuse/circuit  breaker  characteristics. 

PW9 

Hookup  Current 

Fusing,  circuit  breakers,  relays  and  power  supplies  may  require 
additional  margin  to  ensure  they  can  withstand  powering  a  unit 
that  has  not  been  precharged  by  being  connected  to  a  power 
bus. 

Charging  input  capacitors  of  a  “cold”  unit 
can  cause  a  higher  inrush  current  than 
would  be  typical  of  a  turn-on  transient. 

PW10 

Nominal  Bus  Voltage 

Determine  nominal  bus  voltage  operating  range  for  payload. 

Voltage  should  be  specified  at  the  payload 
input  connector. 
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Item 

Topic 

Consideration 

Comments 

PW11 

Bus  Voltage 

Fluctuations 

Determine  payload  requirements  for  off-nominal  power  bus 
voltage  fluctuations  (under-voltage  and  over-voltage  transients). 
Include  operate  through,  survival  and  auto-shutdown 
requirements  for  these  conditions. 

PW12 

Bus  Voltage  Periodic 
and  Random  Deviation 

Establish  noise  environment  for  normal  and  abnormal  operation. 

Could  be  satisfied  by  imposing  EMI  test 
standards. 

PW13 

Single  Point  Failures 

The  Payload’s  power  circuitry  should  not  have  any  unmitigated 
single  point  failures  that  would  cause  the  Payload  to  either 
power  on  autonomously  or  fail  to  respond  to  an  ‘off’  command 
from  the  host. 

If  the  Payload  design  is  fixed,  then  the  Host 
may  consider  implementing  an  isolation- 
capable  power  bus  for  the  Payload. 

PW14 

Telemetry 

Establish  payload  requirements  for  power  related  telemetry,  i.e., 
local  bus  voltage,  DC  current,  on/off  status,  secondary  power 
supply  status,  etc. 

Used  for  fault  detection/diagnosis  and 
assessment  of  performance  degradation. 

PW15 

Connectors 

Positive  power  pins  should  have  physical  separation  from 
ground  pins  and  signal  pins,  i.e.  they  are  not  immediately 
adjacent  to  these  other  pin  types. 

Prevent  secondary  damage  due  to 
bent/damaged  pins  or  foreign  conductive 
particles. 

PW16 

Power  Return 

The  power  return  design  for  the  payload  should  minimize  stray 
currents  and  ground  loops  on  the  host;  e.g.,  electrically  ground 
to  a  single  point  on  the  host. 

Different  Contractors  and  Payload  providers 
may  employ  different  unit/bus  power  return 
architectures:  return  to  single  point  ground, 
chassis  ground,  etc. 

PW17 

Connector  Contacts 

Power  sourcing  contacts  should  be  female. 

Reduces  chance  of  arcing  if  cable  is 
disconnected  when  power  is  applied. 

PW18 

Voltage  Drops 

Voltage  drops  should  be  considered  when  providing  power  via 
cabling  to  a  Payload. 

Voltage  should  be  specified  at  the  interface 
to  the  payload,  rather  than  at  the  power 
source. 
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Safety  and  Reliability 


Safety  and  Reliability  are  critically  important  in  hosted  payload  projects.  While  a  typical  commercial  Host  relies  on  heritage  and  established 
interfaces  to  ensure  compatibility,  attaching  an  independently  developed  Payload  to  an  operational  mission  can  give  rise  to  both  obvious  and 
subtle  conflicts.  Though  analyses  do  not  have  to  go  far  into  a  circuit  to  be  effective,  analysis  of  all  but  the  simplest  interfaces  must  be  deep  to 
ensure  integrity. 

Table  21.  Safety  and  Reliability  Checklist 


Item 

Topic 

Consideration 

Comments 

SRI 

Probability  of  Success 

Agree  upon  a  set  of  reliability  assumptions  for  host  and  payload 
if  probabilities  are  required. 

A  uniform  standard  should  be  used 
for  the  analyses  if  it  is  required. 

SR2 

Interface  Analysis 

Develop  Interface  Reliability  Block  Diagram  and  Interface 

FMECA. 

Payload  should  provide  an  analysis 
of  potential  failure  modes  and,  if 
required,  their  probability. 

SR3 

Probability  of  Success 

Generate  interface  reliability  prediction  for  SPFs. 

Failure  probabilities  of  SPFs  might 
need  to  be  calculated. 

SR4 

Interface  Analysis 

Verify  that  interfaces  are  protected  from  potential  propagating 
failures  that  could  result  in  over-stress. 

Fault  protection  needs  to  be  in  place 
for  Host  and  Payload  interfaces. 

SR5 

Failure  Mitigation 

Failure  mitigation  protection  with  “watch-dog”  timers  that  sense 
“a  loss  of  the  clock”  can  be  included  in  the  timing  system  design 
architecture  as  required. 

These  have  been  used  with  units, 
such  as  focal  plane  arrays  that 
experienced  an  increase  in 
temperature  with  a  loss  of  the  clock. 

SR6 

Failure  Mitigation 

Baseplate  temperature  might  be  controlled  by  spacecraft 
sensors  and  switches. 

If  active  switches  are  used,  two 
series  FET  switches  in  series 
redundancy  should  be  considered,  to 
prevent  a  failed-on  state  which  might 
overheat  the  Payload. 

SR7 

System  Safety  Program  Plan 

A  system  safety  program  plan  should  be  developed  in 
accordance  with  contract  requirements. 

Commercial  programs  may  not 
require  material  and  information 
beyond  that  mandated  by  the  US 
Occupational  Safety  &  Health 
Administration.  International 
programs  may  have  special 
requirements  that  should  be  reviewed 
and  understood. 

SR8 

Failure  Mitigation 

The  Payload  DC/DC  converters  that  convert  the  Host  bus 
voltage  to  the  secondary  voltages  needed  for  its  electronics 
might  have  output  over-voltage  and  current-limiting  protection  for 
mitigating  potential  fault  propagating  failures  back  to  the  Host. 

Power  cross-straps  might  be  “diode- 
ored”  for  mitigating  shorts  of 
“upstream  source  outputs”  and 
current-limit/over-voltage  protection 
to  avoid  over-stressing  “down-stream 
redundant  loads  or  functions”. 
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Item 

Topic 

Consideration 

Comments 

SR9 

Single  Point  Failure 

Prevention 

Ensure  adequate  protection  on  power  lines  leading  from  the 

Host  Power  Bus  to  the  Payload. 

Fuses,  resettable  circuit  breakers  and 
current  limiters  might  be  used,  though 
failure  modes  of  these  devices  should 
be  considered. 

SR10 

Single  Point  Failure 

Prevention 

Product  design  guidelines,  identifying  minimum  spacing  between 
traces  “in-plane  and  between  planes,”  should  be  followed  to 
minimize  the  probability  of  shorts  in  multilayer  boards  or 
backplanes  that  serve  as  a  common  interconnect  for  prime  and 
redundant  functions. 

Potential  SPFs  in  multilayer  boards  or 
backplanes  should  be  avoided  by 
recommended  separation  of  prime 
and  redundant  functions. 

SR10 

Special  Attention  Process 
Steps  for  Accepted  Single 

Point  Failure. 

Consider  use  of  a  critical  item  control  plan  (CICP)  for  single  point 
failure  items,  defining  additional  inspection  and  test  steps  for  use 
during  fabrication  and  test  to  reduce  the  likelihood  of  failure. 

Examples  of  critical  items  are  the 

Host  primary  power  bus  and  single 
logical  output  of  “2  of  3  majority 
voted”  functions  used  in  various 
power  electronics  circuitry  for  battery 
charge/discharge  control  and  related 
functions. 

SR1 1 

Failure  Mode  Prevention 

Be  sure  to  check  for  subtle  failure  mechanisms  such  as 
breakdown  of  body  diodes  in  MOSFETs. 

These  have  resulted  in  unexpected 
“sneak  paths.” 

SR12 

Single  Point  Failure 

Prevention 

Consideration  should  be  given  to  buffering  of  signal  cross-straps 
through  independent  devices  in  separate  packages  to  prevent 
single  point  failures. 

This  will  avoid  a  single  ground  or 
power  lead  failure  in  disabling  a 
multiple  function  package. 

SR13 

Single  Point  Failure 

Prevention 

Power  and  ground  lines  should  be  analyzed  to  ensure  loss  of 
one  connection  will  not  result  in  loss  of  payload  function. 

Potential  failure  modes  in  the 
interconnecting  harness,  multilayer 
boards,  and  backplane  assemblies 
should  be  evaluated. 

SR14 

Operations 

Verify  sufficiency  of  autonomous  failure  detection  and  correction 
is  implemented  for  timely  mitigation  of  failures  in  relation  to  the 
Payload. 

This  process  has  been  used  to 
address  fault  propagation  leading  to 
potential  SPFs. 

SR15 

Critical  Functions 

Verify  that  fail-safe/redundant  configurations  are  used  for  critical 
functions  on  the  Host  and  Payload. 

Examples  are  premature  ordnance 
initiation  and  failed-on  heaters. 

SR16 

Single  Point  Failure 

Prevention 

Verify  that  prime  and  redundant  cross-straps  (e.g.,  telemetry  & 
command,  mission  data,  etc.)  are  isolated  and  buffered  to 
prevent  an  interface  failure. 

Hardwire  cross-straps  of  prime  and 
redundancy  signals  are  always 
potential  SPFs. 

SR17 

Control  of  SPFs 

Verify  that  known  SPFs,  such  as  the  output  of  "2  of  3  majority- 
voted"  logic  have  special  attention  plans  to  reduce  the  likelihood 
ofaSPF. 

Accepted  SPFs  that  cannot  be 
corrected  by  design  rely  on  CICPs  to 
reduce  the  likelihood  of  failure. 

SR18 

Single  Point  Failure 

Prevention 

Verify  that  the  product  design  requirements  for  trace  separation 
between  prime  and  redundant  functions  both  in-plane  and 
between  planes  are  followed  in  common  backplane  and 
motherboard  designs. 

Minimum  separation  requirements 
are  contained  in  the  product  design 
guidelines. 

SR19 

Control  of  SPFs 

Verify  that  all  accepted  SPFs  have  a  Critical  Item  Control  Plan 
(CICP)  identifying  steps  during  the  design,  manufacturing  and 
test  to  reduce  the  potential  of  failure. 

Accepted  SPFs  that  cannot  be 
corrected  by  design  rely  on  CICPs  to 
reduce  the  likelihood  of  failure. 
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Item 

Topic 

Consideration 

Comments 

SR20 

Failure  Tolerance 

Verify  that  there  is  a  positive  disconnect  of  primary  power  from 
the  Host  to  prevent  the  loss  of  the  Host  Primary  Power  Bus  and 
"smart  shorts." 

“Smart  shorts”  are  not  sufficient  to 
“clear  the  fuse,”  but  continue  to 
consume  power. 

SR21 

Failure  Tolerance 

Verify  that  Host  unintended  commands  are  addressed. 

If  timely  re-designs  cannot  be 
completed,  unintended  commands 
have  been  disabled  with  series  relays 
to  prevent  uncontrolled  commanding. 

Structural  and  Mechanical  Design 

This  checklist  covers  structural  concerns  including  alignment  and  mass  properties  as  well  as  issues  related  to  mechanical  design  and  analysis 
of  the  hosted  payload.  Launch  and  on-orbit  environments  are  also  considered  here.  It  is  important  to  note  that  structural  and  mechanical 
requirements  for  Payload  units  will  vary  by  commercial  Host  spacecraft  provider  due  to  different  architectures  and  launch  vehicles. 

MIT , -STD- 1 540  is  a  good  reference  for  the  types  of  test  and  analysis  related  to  structural  and  mechanical  aspects. 

Table  22.  Structural  and  Mechanical  Design  Checklist 


Item 

Topic 

Consideration 

Comments 

SMI 

Mounting  Location 

Available  space  is  needed  for  all  hosted  payload 
components.  Consider  mounting  all  hosted  payload 
components  externally  for  easier  access/installation. 

If  late  addition,  are  all  locations  easily 
accessible  without  breaking 
configuration  (minor  adjustments  may 
be  okay)? 

SM2 

Support  Structure 

Adding  a  separate  support  structure  to  mount  all  hosted 
payload  components  can  be  beneficial  for  integration  and 
testing. 

A  large  solitary  support  structure  may 
need  a  separate/delta  CDR  to  finalize 
design  as  instrument  matures. 

SM3 

De-integration 

Consider  mounting  hosted  payload  externally  or  as  one 
subassembly  to  assist  with  any  de-integration  to  ensure 
host  can  fly  on  schedule. 

If  something  goes  wrong  with  the 
hosted  payload  during  after 
integration,  can  all 
components/instrument  be  easily 
(relatively)  removed  so  that  host  can 
fly  on  schedule? 

SM4 

Ballast  Mass/Mass  Simulator 

Ballast  mass  may  be  required  for  integration  or  testing 
purposes,  especially  if  the  host  will  be  tested  individually. 
Mass  simulators  may  be  required  for  dynamics  testing. 

SM5 

Mounting  large 
components/Physical  FOV 

Large  structures  on  hosted  payload  need  to  clear  all 
physical  FOVs  of  host;  if  they  do  not,  approval  and/or 
additional  analysis  is  required  from  host. 

This  includes  static  and  all  phases  of 
deployment. 

A-23 


Item 

Topic 

Consideration 

Comments 

SM6 

Grounding  Locations 

Ensure  that  grounding  of  all  individual  components  of 
hosted  payload  is  adequate;  one  ground  path  between  a 
hosted  payload  subassembly  and  the  host  is  not 
sufficient. 

If  hosted  payload  was  not  designed 
for  space,  grounding  may  not  be 
adequate.  All  components  need  to  be 
grounded  individually,  not  grounded 
as  one  subassembly. 

SM7 

Host  Component  Adjustments 

Do  host  components  need  to  be  moved  to  accommodate 
hosted  payload  rework? 

Consider  amount  of  time  required  for 
rework  as  well  as  lead  time  for 
additional  support  structures  and 
waveguide. 

SM8 

Flatness 

Ensure  each  new  component  or  support  structure  has  the 
flatness  requirements  needed  for  alignment  or  bond-line 
control  during  integration 

SM9 

Stiffness 

Host  and  hosted  payload  support  structure  may  need  to 
be  stiffened  to  accommodate  existing  hosted  payload 
modes. 

SM10 

Qualification  History 

Hosted  payload  units  may  not  have  qualification  history 
required  for  host  customer;  flight  units  may  need  to  be 
subjected  to  protoflight  vibration  and  shock  testing. 

SM1 1 

Analysis  Levels 

Requirements  need  to  be  flowed  down  to  hosted  payload 
as  soon  as  possible  for  accurate  analysis. 

Environments  for  analysis  and 
required  margins  of  safety. 

SM12 

Coupled  Loads  Analysis 

Coupled  analysis  may  need  to  be  developed  to  ensure 
host/hosted  payload  structural  compatibility. 

SM13 

Mass  Measurement 

Payload  mass  properties  must  be  analytically  derived  to  a 
very  accurate  level  early  in  the  Host  design  phase  and 
then  accurately  measured  prior  to  delivery  to  the  Host. 

Does  the  Payload  provider  possess 
analytical  and  test  tools  sufficient  to 
meet  Host  accuracy/precision 
requirements? 

SM14 

Payload-Induced  Dynamics 

Payload  launch  locks  or  hold  downs  need  to  be  released 
on-orbit. 

Will  release  of  Payload  hold  down 
mechanisms  result  in  significant 
shock  environment  for  Host? 

SM15 

Coefficients  of  Expansion 

Check  differential  coefficients  of  expansion  between  the 
Payload  and  Host  to  ensure  there  is  no  excessive 
structural  stress  and  no  significant  thermally  induced 
pointing  change. 

Depressurization 

Venting  of  structures  needs  to  be  considered. 
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Thermal 


Thermal  design  to  accommodate  a  Payload  is  very  much  like  system  thermal  design  for  a  host  mission.  Conduction  and  radiation  pathways 
must  be  provided  to  dissipate  heat  generated  within  the  Payload,  and  heaters  must  be  provided  to  keep  the  Payload  within  its  operating  and 
survival  temperature  ranges  during  all  phases  of  the  mission  and  during  testing.  The  factory,  shipping,  and  storage  environments  should  be 
controlled  and  the  environments  defined  so  that  any  required  protective  measures  for  sensitive  hosted  payloads  can  be  identified  and  provided. 

Responsibility  for  thermal  control  should  be  well  defined.  The  host  may  provide  some  or  all  of  the  thermal  control  or  the  hosted  payload  may 
need  to  provide  autonomous  thermal  control.  A  cooperative  effort  where  thermal  control  responsibilities  are  shared  is  typical.  Usually, 
survival  heaters  will  be  powered  by  the  host  using  host  temperature  sensors  because  initial  safing  protocol  favors  putting  the  payloads  into  a 
dormant  or  “safe”  mode.  Thermostatically  controlled  circuits  should  be  used  with  caution,  and  mechanical  thermostats  are  not  considered  to 
have  high  reliability  when  applied  without  redundancy. 

Integral  thermal  designs  may  result  in  some  unique  concerns.  Sometimes,  the  thermal  design  baseline  and  mounting  interfaces  may  need  to  be 
completed  very  early  in  the  design  phase  for  heat  pipe  layout  to  be  finalized  and  panels  ordered  in  time.  This  may  drive  early  definition  of  unit 
footprints,  mounting  feet,  and  heat  conduction  paths  because  of  the  need  to  install  inserts  into  the  panels. 

Table  23.  Thermal  Checklist 


Area 

Topic 

Consideration 

Comments 

TH1 

Dissipation 

Are  there  highly  dissipating  units  in  the 
hosted  payload? 

High  dissipation  may  affect  the  panel  temperatures 
defined  as  the  thermal  interface.  This  requires  a  coupled 
thermal  analysis  between  the  host  and  the  hosted 
payload  to  assess  heat  rejection.  Payloads  with  high 
dissipations  require  more  power  and  create  more 
significant  thermal  concerns  making  them  less  suitable 
for  hosted  payload  opportunities. 

TH2 

Thermal  Model 

Does  the  hosted  payload  have  significant 
thermal  interactions  with  the  Host? 

Thermal  models  should  be  exchanged  between  the 
hosted  payload  provider  and  the  Prime. 

TH3 

Mounting 

What  thermal  dissipation  capability  is  being 
provided  with  the  mounting  interface  to  the 
host? 

Thermal  mounting  interfaces  should  be  well  defined 
between  the  host  and  Payload.  Payloads  that  have 
minimal  location  restrictions  are  better  candidates  for 
hosted  payload  opportunities. 

TH4 

Heater  Failure 

Will  a  “stuck  on”  heater  cause  the  Payload 
to  overheat? 

Redundant  heater  circuits  are  required  to  mitigate  this 
risk.  If  heater  failure  is  not  mitigated  with  redundancy  and 
overheating  will  affect  the  host,  the  ability  to  cut  power  off 
to  and  sacrifice  the  hosted  payload  will  be  required. 

TH5 

Active  Cooling 

Does  the  hosted  payload  require  active 
thermal  control  devices? 

Loops,  cryo-coolers  and  other  complex  heat  transfer 
mechanisms  will  require  significant  integration  and  more 
resources  such  as  power  and  real  estate. 
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Area 

Topic 

Consideration 

Comments 

TH6 

Boundary  Conditions 

Has  the  host  defined  the  boundary 
conditions  for  thermally  integrating  the  host 
payload? 

Radiative  and  conductive  thermal  boundary  conditions 
should  be  well  defined  and  managed  by  the  Host. 

TH7 

Radiation 

Does  the  host  have  sufficient  radiator  area 
allocated  for  the  hosted  payload  and  is 
there  a  strong  thermal  path  to  that  radiator? 

The  location  within  the  spacecraft  and  the  amount  of 
radiator  area  allocated  to  the  host  payload  for  heat 
rejection  are  critical  factors  for  assessing  host 
compatibility. 

TH8 

Reflections 

Does  the  host  or  hosted  payload  have 
highly  reflective  surfaces? 

Reflections  from  the  payload  and  host  should  not  provide 
thermal  accentuation,  such  as  “double-sun”  conditions. 
Highly  specular  surfaces  could  cause  directed  light  that 
interferes  with  mission  functionality. 

TH9 

Programmable  Heater 

Control 

Is  the  hosted  payload  implementing 
programmable  heater  control? 

Programmable  heater  control  of  the  Payload  represents 
a  significant  integration  effort  with  the  host.  Can  heater 
parameters  be  updated  once  on-orbit? 

TH10 

Thermal  Backload 

Are  there  payload  appendages  in  the  field  of 
view  of  thermal  radiators? 

Host  appendages  in  or  near  the  Payload  radiator  may 
result  in  undesired  IR  backloading.  Similarly,  Payload 
appendages  may  create  backloading  concerns  for  Host 
radiators 

TH11 

Non-operating  Survival 

The  host  payload  should  assume  that  power 
may  be  cut  to  their  system  for  extended 
periods  of  inactivity,  e.g.,  during  launch, 
orbit  raising,  in-orbit  test,  and  contingency 
operations. 

Survival  heaters  must  be  sized  to  accommodate  worst- 
case  non-operating  periods.  Control  of  these  survival 
heaters  is  usually  a  host  responsibility. 

TH12 

Host  Payload  Thermal 

Safing 

The  Payload  may  fail  or  complete  its 
mission  prior  to  the  end  of  the  host  mission. 

The  thermal  environment  in  this  situation  should  be 
verified  to  not  cause  physical  degradation  of  materials 
within  the  Payload. 
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Appendix  B.  Hypothetical  Payload  and  Payload  Interface  Equipment  FMECA  and  Propagating  Failure  Lists 


Payload  Interface 

Equipment  1 

FMECA 

Item 

No. 

Block 

No. 

Function 

Failure 

Modes 

Failure 

Causes 

Effects  on 
Payload 

Effects  on 
Spacecraft 

Observable 

Symptoms 

Compensating 

Provisions 

Crit. 

Recommendatio 
ns  or  Remarks 

1 

1 

Power 

Control 

Low  Voltage 
Converter 

Qty  =  2 

Fault  at  the 
power  input 
connection  to 
the  power 
supply 

Broken  or 
failed 

connection, 
mechanical 
failure.  Open 
circuit  or 
short  of  main 
bus  input  to 
ground. 

Loss  of  all  low 
voltage  output 
power  to 
payload. 

None 

Payload  status 
telemetry 

IS 

A  fuse  is  provided 
upstream  to 
prevent  loss  or 
degradation  of 
the  main  power 
bus. 

2 

1 

No  output 
voltage  or 
current. 

Random  part 
failure,  failed 
solder 
connection 

Reduced  power 
available  to 
payload 

None 

Payload  status 
telemetry. 
Performance 
degradation  of 
payload  may 
be  detectable. 

IS 

3 

1 

Short  at  the 
output  of  the 
power  supply 

FODor 
electrical 
short  to 
ground  at  the 
output. 

Short  to  ground 
at  payload  input. 

None 

Payload  status 
telemetry. 
Performance 
degradation  of 
payload  may 
be  detectable. 

IS 

4 

2 

Additional 

functions 

and 

equipment 

Payload  Interface  Potentia 

Propagating  Failure  Item  List 

Subsystem 

Item 

Quantity 

Failure  Mode 

Failure  Effect 

Payload  Failure  Effect 

Crit. 

Payload  Support 
Equipment 

Power  Supply 

2 

Loss  of  power 

Reduction  in  available  power  from  800 
Watts  to  400  Watts 

Requires  Evaluation  by  Payload 

IS 

Payload  Support 
Equipment 

Power  Hub 

1 

Open  wire 

Loss  of  power  to  one  module 

Loss  of  one  module.  Further 
evaluation  to  be  done  by  Payload 

IS 

Payload  Support 
Equipment 

Fuse  Block 

5  Fuses 

Open  fuse 

Loss  of  power  to  one  module 

Loss  of  one  module.  Further 
evaluation  to  be  done  by  Payload 

IS 

Payload  Support 
Equipment 

Power  Switch 

5 

Open  contact  or  failure  to 
switch  on. 

Loss  of  power  to  one  module 

Loss  of  one  module.  Further 
evaluation  to  be  done  by  Payload 

IS 
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Hypothetical  Payload  FMECA 


Item 

No. 

Block 

No. 

Function 

Failure 

Modes 

Failure 

Causes 

Effects  on 
Payload 

Effects 
propagating 
to  spacecraft 

Observable 

Symptoms 

Compensating 

Provisions 

Crit. 

Recommendatio 
ns  or  Remarks 

1 

1 

DC  to  DC 

power 

converter 

Open  at  the 
power  input 
connection  to 
the  power 
converter 

Open  circuit 
or  trace  on 
the  power 
line. 

Loss  of  all 
voltages  to  parts 
of  the  payload 
powered  by  this 
converter. 

Reduced 

redundancy. 

None. 

Payload  status 
telemetry 

1 R 

2 

1 

Short  of 

Input 

Capacitors 

Random  part 
failure,  failed 
solder 
connection 

Loss  of  power 
from  this 
converter 

Short  of  input 
power  to 
return 

Payload  status 
telemetry. 

IS 

Fuses,  relays  or 
fold-back 
converter  might 
reduce  effects  on 
the  spacecraft. 

3 

1 

Fault  at  the 
power  output 
connection  of 
the  power 
supply 

Broken  or 
failed 

connection, 

mechanical 

failure. 

Reduced  power 
available  to 
Payload 

None. 

Payload  status 
telemetry. 
Performance 
degradation  of 
Payload  may 
be  detectable. 

IS 

1 

2 

Additional 

functions 

and 

equipment 

1 

Payload  Potential  Propagating  Failure  Item  List 


Subsystem 

Item 

Quantity 

Failure  Mode 

Failure  Effect 

Host  Failure  Effect 

Crit. 

Payload 

DC  Converter 

2 

Input  short  to  ground 

Short  of  power  input  to  return 

Requires  evaluation  by  Host 

IS 

Payload 

Telemetry  Point 

4 

Open  wire 

Open  wire 

Causes  wire  to  not  have 
connection  to  ground.  Further 
evaluation  to  be  done  by  Host 

IS 

Payload 

Telemetry  Point 

4 

Short  to  ground  or  return 

High-side  of  telemetry  is  connected  to 
ground. 

Requires  evaluation  by  Host 

IS 

Payload 

1553  connection 

2 
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For  these  examples,  the  following  criticality  codes  are  used.  These  typically  vary  somewhat  by 
manufacturer,  but  are  relatively  similar  across  industry. 


Criticality  Categories 


Criticality 

Categories 

Assembly/Equipment  Level 

Subsystem  Level 

Spacecraft  Level 

1 

Failure  mode  results  in  risk  of 
loss  or  degradation  of  other 
equipment  (risk  of  failure 
propagation)  or  constitutes  a 
safety  hazard. 

Failure  mode  results  in  risk  of 
loss  or  degradation  of  other 
functional  subsystems  (risk 
of  failure  propagation)  or 
constitutes  a  safety  hazard. 

Failure  mode  results  in 
complete  loss  of  the  spacecraft 
and  all  of  its  missions  (referring 
to  specified  requirements)  or 
constitutes  a  safety  hazard. 

2 

Failure  mode  results  in 
complete  loss  of  operational 
capability  of  the  equipment 
under  consideration. 

Failure  mode  results  in 
complete  loss  of  operational 
capability  of  the  subsystems 
under  consideration. 

Failure  mode  results  in  partial 
loss  or  severe  degradation  of 
mission. 

3 

Failure  mode  results  in  severe 
degradation  of  operational 
capability  of  equipment  under 
consideration. 

Failure  mode  results  in 
severe  degradation  of 
operational  capability  of 
subsystems  under 
consideration. 

Failure  mode  results  in  only 
minor  or  negligible  degradation 
of  mission. 

4 

Failure  mode  results  in  only 
minor  or  negligible 
degradation  of  equipment 
under  consideration. 

Failure  mode  results  in  only 
minor  or  negligible 
degradation  of  subsystems 
under  consideration. 

(No  category  4  for  the 
spacecraft.) 

The  criticality  designations  are  further  classified  into  those  that  result  from  single-point  failure  items 
(S)  and  those  resulting  from  failure  of  redundant  items  (R). 
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